This is our first time using an Opto22 ‘Modbus Subroutine’ - “O22Modbus04ReadInputRegistersAsInt”
We will be interfacing with a small Nanotec motor that will drive an Actuator, so we will need to send (write) various ‘Move’ commands to internal motor registers.
We have verified the ability to ‘R/W’ with the motor using a ‘Modbus Scanner’ program, this seems to work.
We are starting testing with an example ‘Modbus Communication’ Strategy from an Opto22 vendor and are assured the example Strategy works. We are using this Strategy for testing that our we can ‘R/W’ to the motor before adding logic into an existing larger Opto22 Strategy Project.
Some info on our setup and questions: (for starters)
Setup: SNAP-PAC-R2 running on Firmware r10.4d, using v10.5 PAC Control Basic (the final project will be using a SNAP-PAC-R1 ‘Gen2’ controller)
Questions: How can you tell if the ‘subroutine’ is running (similar to a Chart)? … The 7 parameters that are supposed to get ‘passed’ into the subroutine do not seem to be getting ‘passed’ … Continue to receive a ‘-216’ Timeout subroutine error … The Chart that contains the parameters to be passed is ‘Running’
The timeout tells you the subroutine is being called, it just isn’t receiving a response. Check your comm channel settings, or tells us how you have it set and what the device is configured for so we can verify if that is set correctly. Is it TCP or RTU?
We are trying to get Modbus RTU to work, we are trying to match the Nanotec Motor comm settings of a Baud Rate of ‘19200’ and Parity of ‘even’. The Comm Handle ‘chModbusMaster’ is set to ‘tcp:127.0.0.1:22500’. We are using an Opto22 ‘SNAP-SCM-485-422’ module (as this is what is used in the unit we are updating a new actuator), we have the module set up on ‘Port A’ 22500, the Baud Rate & Parity were setup using PAC Manager. We are currently testing using a SNAP-PAC R2 controller with Firmware of ‘R10.4d’, but the controller in the unit being upgraded will be using a SNAP-PAC-R1 Gen2.
This is first foray into the Modbus RTU communication, up till now we have been using simple serial communication to other motors, pumps, etc. using the SNAP-SCM-485-422 module.
This is also our first foray using the O22 Sub Routines. I noticed that we were working with a provided example strategy that was using the Sub Routine for ‘Read Input Registers As Int’. During our testing with a ‘modbus scanner’ tool, we were r/w to ‘Holding Registers.
Would a good step be to use the Sub Routine for ‘Holding Registers’? I think we’ll give this a try.
If holding registers were working on your tool (Modbus function code 3), then yes, use holding registers on the Opto Modbus kit. Since you already are familiar with the serial modules, the config is the same, so you are probably good there.
Yes as Phillip said, holding registers are most commonly used. Did you figure it out?
When using the serial modules on Snap, make sure you are using the right port number for the right moule and chanel (1/2) of the module. Also, don’t forget to save the brain side of the R1/R2 to flash after making any changes to the port configs. To avoid using the Brain flash config, you can instead write to the registers that set these values directly in you script at top of your chart.
I had used the brain config and forgot to save it on a job and 2-1/2 years later the brain got rebooted and nothing worked….
Other than the fact that if the chart is running and the sub is in the logic, it is running the sub. Use break points to step through the logic and step into the logic at the sub will open the sub window and let you step through the entire sub logic.
Opto’s Mb routine does work well, generally if there is a problem it is a standard no reply issue of some other Modbus code or Opto’s subroutine code that will be issued to help troubleshoot.
That must of taken a bit to figure out after 2 1/2 years. My brain reboots much more frequently than that…,
Yep, once configured correctly of course. With the ability to have nested subroutines, I’ve revamped/rewrote these to have separate subroutines for different data types and single values vs arrays of values. Much easier for me to keep straight.
Yah, it took me a couple f looks before I caught on…
I have also created some versions, in fact I had created a crazy version that used a set of tables to store what the last read value was of a var that was r/w, so that if it changed from the last written value, it would automatically write the last write value or something like that. The idea was to make the write of a var automatic based on a change.
Once you get the hang of their Mb routines, you can do some neat stuff. I once had a conveyor system with grinder to turn Eggo’s into hog feed…there was 9 smaller drives and 1 big drive that I talked to with Mb rtu. Used an S1 to run 6 racks and had all 10 of those drives connected to modules on one rack. Because you can call more than one Mb sub at a time, I had more than one chart calling Mb rtu subs and was able to talk to all 10 drives 3 times a second over 9600 baud serial (because the drives baud rate was maxed), while the rest of the entire process was being ran with 500ms updates to Pac Display. The beauty is that while the Mb sub runs, the chart is suspended allowing the cpu to keep doing other charts while multiple subs are running in the background.
