Thanks again Philip,
My apologies for not knowing how to quote a line from your post, as you have so nicely highlighted mine, so I’ll copy and paste with quotes:
“I think this is going to be a function of the serial module itself and is likely deterministic and may be based on the baud clock even, so faster baud rates would switch faster.”
So, the serial module (SCM-485-422) is a “smart” module with deterministic delay(?) and doesn’t depend on the R1’s other activities at the time? Your use of “likely” does bother me though. OK then. I knew all along that part of my IO controller response was lost because of being faster than the combination R1 and SCM “turnaround time”, thus resulting in a partial (garbage) message at the receiver end, so we are in total agreement on that.
“I don’t know how long it takes for the transceiver to switch to receive and that would be good to know, but it is normal for slave devices to have a turn around delay before they respond to allow the transceiver to switch (I know this is in the modbus spec, 3.5 character time).”
You’re 100% correct about having a “turn around delay” but it has to be specified. I just need to know what the worst case delay would be and set my delay accordingly and with margin. The Modbus Spec (which I have used many times) came up with that rather awkward 3.5 time value as a safe delay to allow controllers to switch from Tx to Rx without missing an important and perhaps critical response.
However, independent of baud rate (mine happens to be 38400/no parity/1-stop) the turnaround time at the Opto22 end should be known and published and guaranteed in order to ensure normal communication and prevent possibly disastrous results for interpreting an erroneous response that doesn’t show up in the “status” variable.
For me, my engineering side says that even though my “guessed” delay of 10ms or my shorter 1ms value made communication from the I/O controller work very well, it still leaves me a bit uncertain that I’ve covered all real world circumstances.
Someone at Opto22 should know whether the SCM “turnaround time” is a deterministic value, as you suggest, and if so what is that value? If not deterministic, being for example that the “turnaround time” is partially a function of the real-time kernel the R1 Chart is operating under, then someone at Opto22 should know the worse case “turnaround time”.
A value for either the deterministic or worst case scenario, whichever it is, as long it’s accurate, will help me sleep better knowing that the machine will not crash randomly with no trace as to why (followed by a lot of yelling and screaming, threats of tar and feathers and much broken glass). If I missed this critical number somewhere in Opto22’s docs, I apologize. Please lead me directly to that doc.
By the way, the machine bottles Beer, so your beers are on me if you can help.
Highest regards to all,
Fritz E Noll