AC800M varying transfer times from Com 3 to program (SPA protocoll)
We've implemented the SPA protocoll (master) on the Com3 port of AC800M by using SerialCommLib fb's. The communication works and for every request we get a response (and data). The issue is that the updating time from the serial port to the program varies a lot; sometimes the updating is almost immediate (< 1s) but at worst it can take up to 5s until we can see the updated value in the program. By checking the Com 3 led's we can see that the response from the slave is immediate. At this phase we're triggering the request manually one at a time so the reason can not be occasionally failing response; for every request we get a response.
Any ideas which might be the reason? Does this has something to do with the String data type? Cpu load is very low so it's probably not a priority related issue.
Manual request at read block??? How many read blocks are you using?
In case it is only one, I can suggest using the following request code:
In case of more blocks, the request for the next read block should come at Ndr OR Error output of the previous block = consequence execution of all read blocks.
Also check the task time of the application, where the read block is placed.
Of course, COM port settings are also important - in case you send a print screen, could check if they are correct
Without seeing your code, it's impossible to say what you have or haven't done.
However, your comment that the read blocks are "not chained" but are triggered manually seems strange. Chaining the read blocks on a custom serial interface is necessary to ensure that you read ALL of the characters from the serial port and that part of the message is not left behind in the buffer.
If you're actually receiving all of the data, then I'd suggest that you possibly should complete the program correctly before trying to analyze timing problems with it.
it seems that the problem was only visual; the string data type variables are updated very slowly (on a very slow cycle) on CB's online display. You can see the same with e.g. Mux with string type variables. When the value of the selecting input is changed, it will take many seconds until you can see the selected string on the output (this happens only when you have a real controller, in test mode the change is immediate). However, the actual value changes as expected, you just see it after a few sec delay. Our mistake was that we were watching the 'raw' response message string when noticed the delay. If we had completed the coding and stripped off starting, stopping characters etc and changed the data type to bool/real we would not have noticed any problems.
When the length and form of the response messages is known, the best way to debug the communication is to use manual triggering (at least in this case). Then it is easy to analyze the responses to every type of requests, don't you agree?
In addition to your investigation, I could recommend using of diagnostic outputs of Read block - Ndr and Err. You can create simple logic for monitoring of this two binary outputs and register error conditions (for eample with RS triggers at Err output).
In case you receive only Ndr and don't receive Err output after request of Read block, everything is OK. Also you can measure the real respond time of reading, looking the time between two consequent Ndr activations. Ndr and Err are active for only one cycle, after the block is executed.
OnLine mode is very usable for debuging of the logic, but you can't be sure if you "see" fast processes, or real update time of variables - for that you have to create software monitors.