brian.zuelke Posted March 23, 2012 Share Posted March 23, 2012 We had a need to design a custom Modbus device. We are interfacing with this device through the RS-485 port of an ADAM-5000L/TCP from Advantech. The ADAM-5000L/TCP is a Modbus/TCP device, and if you send it a message addressed to any other device than #1, it will convert it into a Modbus/RTU message for transmission on its RS-485 port. The custom device accepts "03" commands from the master, and sends back an array of 36 16-bit values. There are two of these devices on one RS-485 line of the ADAM. One has the device # of 10 and the other of 11. There is no problem when only one of the devices is queried for data. The problems appear when both are queried for data. Data requests are formed in DAQFactory simply from defining the individual channels to request in the "CHANNELS" drop-down, with channel #'s of 1 through 36. The timing is once per second with no offset between the two devices. Here's the problem: When we look at the communications on the RS-485 lines, it looks like DAQFactory is sending a "device #10, give me data" and a "device #11, give me data" request rapid-fire, not waiting for one or the other device to respond before requesting data from the other device. Is this how DF does things? I would have predicted that DF sends one request, then waits for a response, then sends the other request, then waits for the response. Then again, given that this is Modbus/TCP, that's probably not the case. Setting the timing offsets does not seem to help. We separated requests by 0.2s relative to one another, and our devices can definitely respond within that time-frame. Any suggestions, or might we be missing something? Regards, Brian Link to comment Share on other sites More sharing options...
AzeoTech Posted March 24, 2012 Share Posted March 24, 2012 That is not the case, and DF protects the frame. This is, in fact, why many people get port locked errors. DAQFactory is busy waiting for responses and can't send another one until its done. That said, it is most likely an issue with the way you set things up. One possibility: did you create two devices, both with the same TCP port? DAQFactory won't recognize these as the same, and will try and communicate with both devices at the same time. This allows DF to communicate with multiple Modbus TCP devices (or even RTU on separate serial ports) simultaneously. On a side note, I'm assuming you are using the Adam unit for more than a protocol / serial to Ethernet converter. I say this because DF can talk ModbusRTU over Ethernet, so a simple serial to Ethernet converter would suffice. Link to comment Share on other sites More sharing options...
brian.zuelke Posted March 26, 2012 Author Share Posted March 26, 2012 Yes, the two devices are attached to the RS-485 port of the same ADAM-5000L/TCP unit, and DF communicates with the ADAM through port 502. I think this port number is required by the ADAM unit, so I don't think there is a way to address the Modbus/RTU messages through different port numbers, thereby circumventing the communication optimizations in DF. Well, anyways, I was planning on moving to a manual channel polling sequence anyways, so I can simply add a delay between communications to avoid this problem, yes? Link to comment Share on other sites More sharing options...
AzeoTech Posted March 27, 2012 Share Posted March 27, 2012 If you switch to manual, yes, though you can achieve the same thing somewhat by using Offset, though with less control. However, did you actually create two devices in DAQFactory? Maybe post your .ctl doc, or email us at support@ if you don't want it public. I still recommend using a standard Ethernet to RS485 device instead of a protocol converter. Than you could just do ModbusRTU over Ethernet directly to the 485 chain. Link to comment Share on other sites More sharing options...
brian.zuelke Posted March 28, 2012 Author Share Posted March 28, 2012 The way our set-up works, we have a single "Device Type" (AdamA, AdamB, etc.), and the two custom Modbus peripherals are either at device #10 or device #11. It may be that we are not watching for the right events on the O-scope. I need to talk more with the coder who was doing the troubleshooting. Anyways, it was fairly trivial to integrate a delay between the device polling by simply creating POLL_EVEN_DEVICES and POLL_ODD_DEVICES sequences, then putting a delay between their beginseq() calls. I'll update this thread if I am still having troubles. Regards, Brian Link to comment Share on other sites More sharing options...
AzeoTech Posted March 28, 2012 Share Posted March 28, 2012 OK, but doesn't sound to reliable unless you are solely using wait(). Also, you are chasing the symptom (collisions), not the cause of the overlap. If you find the cause, then the workarounds for the symptoms won't matter (and won't fail on you down the road) Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.