How do I resolve a device response delay while using the Free Protocol driver?

kcoiner · May 9, 2024, 3:52pm

HMI Model: cmt-svr-100 (and cmt-3162x)
EasyBuilder Pro Version: V6.09.01.556

I’m attempting to use an SVR as a gateway to pass an ASCII message from a scale with an rs232 output to an ethernet network. My issues pertain to the rs232 half of the application.

To demo the functionality I’m attempting to use two CMT devices (a cmt3162X is my pretend rs232 scale) both using the free protocol driver to write and read ascii messages. I get the below symptoms with traffic in both directions, they are not specific to either device.

If I manually trigger the write and read with single activation, they work as expected every time. When executing cyclically, the inport functions all behave inconsistently with a repeatable pattern. If I’m sending a string of 10 characters, and reading with the basic inport, inport2 or inport3 functions, it looks like a repeating pattern occurs where some fraction (>50%) of the strings recieved only come in as a string of 5 instead of 10, then it grabs the first half of the next message to finish filling out the string, OR sometimes it just finishes and says it read 5 characters, which it might be the first or last half of the original 10. inport4 helps, as I can “mask” the bad reads by only writing to local memory when the proper read amount occurs in combination with looking for the correct ending character, then purging the port buffer after the read takes place, but watching it misread every other message or 3 of every 4 messages as a half length message is odd and it appears to be happening in a consistent repeating pattern.

If i write at a faster, slower, or matched period rate to the read frequency, it doesn’t improve my ability to reliably read the correct data. (though if i write faster than the read rate, i need to make sure i’m purguing the buffer between reads or it accumulates and im no longer reading the latest data. if i don’t purge, the reads DO all read the correct data & length from the buffered data, but the data is increasingly “behind” actual values so this isn’t acceptable. The actual application will be outputting an asynchronous message pattern so there’s no way i can try to match my read cyclic rate to the write rate, i need to find a way to make sure my reads are capturing the whole message each time it comes through.

How does the inport function decide what marks the start or end of a message string? It seems to be able to correctly tell the breaks between messages that have accumulated in the buffer. However, is it accidentally seeing something that’s being interpreted incorrectly as the start of a new message half through my character string when I trigger a read midway through receiving a message?

TimWusa · May 9, 2024, 9:54pm

Perhaps you could do something similar to your macro of the “master” device.

The Yellow section:
After sending a command using the “OUTPORT” function, the device m ay take some time to respond. The response delay depends on how data is handled by the target device as well as the interface type and configuration. To account for this delay, I recommend using a DELAY() function within a “while” loop as in the example below:
Note: This method will allow you to define a dynamic timeout based on delay x loop. We expect that the device will respond faster than the loops maximum value multiplied by the delay time, which in this case is 1s. However, if the device does not respond within 1s, we may consider the device offline. If we do not use this method and choose an arbitrary delay or no delay at all, there is a chance that we may attempt a “read” before the device actually sends a response.

The Green section:
Use an “if” statement to check if the recieve_len or “length” variable is greater than 0. This will allow us to determine when we’ve received a response