Modbus serial communication between Freelance and Quadlog


Thread Starter

Igor Mazursky

I have a system where Freelance DCS works as a Modbus master and Quadlog as a slave. Even with 19200 baud rate communication is unusually slow. There are no communication errors indication on either master or slave side. If I replace Quadlog with Mdbus modbus simulator the communication speed is normal. The com speed is reasonable as well if I use Mdbus to simulate the master. Any thoughts?
Maybe check the resource blocks page of your Quadlog and see what your scan rate is and what your PCTCOM and MAXCOM is on the resource_status block, you could be dealing with a loaded up processor whose scan rate is too low to accomodate its program, good luck.

Been speaking with Siemens. Quadlog will only process one Modbus block per scan. I have quite a bit of Modbus communications and stacked into Modbus data arrays and the Quadlog is very slow to answer. Siemens official line is that they don't support what I'm doing any longer. I'm polling Quadlog with Wonderware Intouch with very poor results. ? 1 minute return on data +- ?. My long term plan is to get rid of Quadlog. Any one else got an idea on how to make the Quadlog talk Modbus at a reasonable rate?

Lynn August Linse

Are you seeing errors? I have >NO< experience with the Quadlog, but things I have seen in various third-party devices which create long lag are:

1) if you poll the device too rapidly after its last response, it might NOT yet have its RCV circuit enabled. The symptom is every other poll fails. The sol'n is to make sure you have at least a 100msec 'gap' between the last response and a first new poll. 100msec is likely overkill, but something to start working with. Some ports have RTS/CTS radio toggle used to delay comms after an RTS/CTS change to permit radio power up/down - this setting can often accomplish this delay.

2) I have seen devices which literally turn OFF their RCV circuit after they see the first byte of a Modbus poll NOT intended for them, then leave the RCV circuit off for some period of time (I've seen up to 250msec). This means if you poll 1 and only 1 device, it is very responsive, but as soon as you poll a second device, this first one becomes unresponsive for some period of time.

3) Devices which are not native Modbus - especially those using some form of internal 'BASIC' to mimic Modbus/RTU can have very bad response patterns. For example I worked with a bottle inspection machine once where normally it replied within 500 msec or so, but when it was busy rejecting a bottle (on a beer line), it might not answer for 10 seconds or more, and if you'd been repolling once a second you'd literally get many responses concatenated as it blindly answered ALL queued requests. The solution was a very long timeout (we used 20 seconds - and this 'Modbus' option had cost the customer a $5000 premium! :-] ).