I recently came across a wireless device that uses Modbus mapping. So I quickly interfaced it with Groov Server (demo version). Everything works great. I was impressed how easy it was to use this wireless device on my network (seriously, it took less than 5 minutes). With that said, I want my PAC-R1 to read/write values out of this little device. So, where do I start to get my R1 to read/write to this device over Ethernet.
Our ModbusTCP toolkit should be just the thing to get that setup.
http://www.opto22.com/site/downloads/dl_drilldown.aspx?aid=4206
Ugh… Is PAC Control modbus ever going to be as easy as the groov?
The modbus toolkit for PAC has a lot more capabilities - making it more complex, BUT you are right, it could be easier - now that we have nested subroutine capabilities, nothing is stopping anyone from encapsulating the toolkit to allow for simpler calls.
Since I use modbus quite a bit from PACs, this is something I’ve been working on when I have spare time (short supply lately).
I get that, but it seems other companies make adding a modbus device/registers only slightly more complex than adding a variable, they still maintain the multitude of capabilities and then the registers show up as variables.
I would love for the modbus device(s) to show up under I/O units in the tree just like any other device. Opto must have some inkling how to do this, after all the groov does this (in a simpler form).
Yeah, I see where you are going - having the ability to add IO units for other protocols - that would be nice.
Thanks for all the input guys. And yeah, I was looking for something easier like nick is saying, but I’ll have to dive into the “kit” when I get home. I can’t do anything at work any more, IT has my PC on lock down it seems.
You say you use Modbus quite a bit with PACs. I was only introduced to Modbus last year and I’m still learning as I go. One thing I wanted to ask: If I had say 20 Modbus/TCP devices, and I was trying to continuously read/write to them, how fast can the PAC controller “hop” through all the devices? In the example, let’s say the 20 devices each had a ping rate of 20ms and I was only trying to write one word and read one word to/from each. How long before each device was updated? Have you done something similar to this?
Short answer. It depends.
Long answer. Just because the device pings in 20ms does not mean that it has Modbus data ready to read, or that it can respond to a Modbus (write) command that quick (remember, PING is almost at the hardware stack level).
Point is, you need to look at the data freshness and poll response time for the Modbus device to see what its typical response time is.
That said, with some careful tweaking (setting a timer and not allowing the PAC to wait for a slow or timed out device) of the PAC R controller code, you should be able to get through the 20 devices as quick as they will allow.
My experience, as implemented, modbus/TCP is slow. It takes a long time for the modbus chart/kit to cycle through multiple devices. If you are wanting mSec responses, it won’t do it, not with multiple devices. Not in my experience.
I was reading 6 ABB drives over modbus/TCP on a high speed machine and the modbus would not keep up reading and more importantly writing to the drives and I had to go to digital/analog I/O on the drives in order to keep up. Perhaps Philip has some tricks up his sleeve.
The Opto22 Modbus toolkit is completely synchronous, which means it will wait for a response or timeout before it returns to your calling chart. So if you want to send a modbus command to two modbus TCP devices at the same time, then you need to run two separate charts. This is fine for most circumstances where you have a low number of devices/serial lines, or if you don’t need real quick response times.
I have been working on writing some modbus subroutines that allow asynchronous commands (which are inherently more complex to work with). The subroutine transmits the command and then returns, the next call will see if there is any response, and if not, immediately return. If it gets a response, it will then process it and return it. So you have to pass a “state” table to the subroutine each time you call it, and then check the status when it returns to determine if you are done or not.
If you are interested, I could send you a copy if you are willing to test - I will need to clean up my “test” strategy first though.
Have you had any luck with ABB drive control over their serial port? - I have had too many issues with them to trust it - mostly configured as BACnet though. I just run control wire for command signals and use the serial for “extra info”.
Yeah I ran some tests on this little I/O device and it works good with groov server (reading about 8 tags), but for some reason once the trial period runs out it messes with the device and I have to reboot the device. That’s not good. I’ll have to run it on my AR1 and see if it works better. I did a job last year that involved 4 wireless Ethernet controllers (PtMP) and I could map modbus tags in each controller and groov server worked very good, it was fast too. Although, I only had a single page per device. So I don’t know if there would be issues if I had multiple tags to multiple controllers on the same page in groov. Anyone with any experience with that scenario?
As far as using a PAC-R1, I have not tested it with the Modbus toolkit and it sounds like it couldn’t reach the speed I would want. I was hoping it could potentially get updated values on multiple devices in less than a second. Again, going back to what Beno said, it will depend on the specs and what type of device you are using. Well, I was trying to use these inexpensive wireless i/o devices.
I appreciate the feedback on this.
After thinking about it. If I already have an AR1 Groov Box (for test purposes and only 1 node) and I want to add multiple devices to it. How much would it cost to upgrade it? My 1 year is almost up, would that upgrade renew my support?
I ran a quick test on SoftPAC to a Modbus simulator set for a 50ms response delay reading 10 registers from 10 devices over a 10 second period.
Synchronous results:
107 total reads - 10.7 reads/second
Asynchronous results:
1280 total reads - 128 reads/second
I’m kind of puzzled that the performance increased by more than 10 times.
On an R1, the results will be slower than SoftPAC - but his largely depends on the network and remote device latency as that will impact the R1 and SoftPAC equally. R1 will be slower on the network stack and compute power for request and response processing. I’ll test this later.
Interesting. Maybe I’d be able to use SoftPAC. I don’t know if I’ll ever end up with 10+ devices, but wanted to make sure whatever hardware I choose, the system can be upgraded with more devices. I am only reading 5 - 16 bit registers continuously per device and writing 2 - 16 bit registers occasionally.
I haven’t used the serial port. I am using the Ethernet I/P module which has been reliable, but not very fast. I too am now using wired control for anything that needs speed and modbus for other info and/or controls with a lower throughput requirement (refrig. control). I wish Opto would license EtherCAT. That is a super fast protocol.
I ran the same test on my R1, but it is not local to me right now, so I tested it over a VPN connection with 100ms average latency.
Sync results:
71 total reads - 7.1 reads/second
Async results:
338 total reads - 33.8 reads/second
Most of the slow down was due to the added latency, not because of the R1. I ran the test again with SoftPAC, but changed the simulator latency from 50ms to 150ms and I get:
Sync results
54 total reads - 5.4 reads/second
Async results
580 total reads = 58.0 reads/second
Since the latency is variable on the R1 test, the actual results very a bit more. I don’t think you will need SoftPAC to get the performance you are looking for. I’ll run the test again when I am on the same network as the R1.
I will go through and figure out the “Modbus kit”. Then, I will run a test with this little i/o device and an actual PLC with Modbus addresses in it and compare. The PLC is 3 times the amount as the wireless I/O device. So if I can use the wireless i/o device, it will save me some time and money. Especially in the cases where I’m only reading one status input and one analog input. This project is only in the preliminary stages, just want to choose the correct hardware.
I appreciate all the feedback.
What is the wireless IO device you are speaking of?
I sent you a link to the device. I don’t know how long it has been on the market.
I got the Modbus kit up and running. I just left everything as the default values except for my IP address and which register I wanted. How often is this reading this register value? Every second?
Never used a sub before and didn’t realize you can’t view the status of a sub variable??