It Seems "ARD" Instruction hangs up sometimes after an "ACL" instruction executes.
Processor: 1756-L55 / V16 firmware
Program Steps:
[ARD] Waits until buffer has 150 Characters (Reply from A device)
[ARD] grabs the 150 bytes and immediately afterwards input buffer is cleared via an [ACL] instruction.
At this point, it seems the Error bit is set in the [ARD] instruction and the error code is "e".
This is where I am confused a bit. I am clearing the error bit and the Hex error code in logic, but Logic scan shows Error bit set for the [ARD] instruction. I am assuming this is because the instruction updates Asynchronous to the logic scan. However when in this state, the [ARD] may or may not operate.
I.e. seems to get stuck in an unknown state and no data is grabbed again from the buffer.
If it hangs, I can get it to go again by going in to Tag Data monitor and manually toggling the run (.RN) bit and it starts executing again.
My questions:
1. Why is ARD go in to an error state when an “ACL” clear buffer executes?
2. What’s the proper way to detect and recover a stuck “ARD” instruction?
3. When “AWT” instruction is sent (CMD to device), how long before buffer has the reply? (assuming 9600 baud comm’s) under 250ms for 150 Byte (ascii Characters) reply?
If Buffer is not cleared, logic executes perfectly and I have no problems with comm’s as long as I am only sending one command and the response to it is 150 bytes. But I need to be able to handle varying data length responses sent from the device for many different commands sent to it. Device does not use LF/CR or a common delimiter for all of the responses and some command replies can vary dynamically based on certain conditions. So I need to start with a fresh buffer each time a new command is sent to the device so I can handle the input appropriately.
The comms between the PLC and Device are Synchronous and PLC is the Master.
Thanks
Processor: 1756-L55 / V16 firmware
Program Steps:
[ARD] Waits until buffer has 150 Characters (Reply from A device)
[ARD] grabs the 150 bytes and immediately afterwards input buffer is cleared via an [ACL] instruction.
At this point, it seems the Error bit is set in the [ARD] instruction and the error code is "e".
This is where I am confused a bit. I am clearing the error bit and the Hex error code in logic, but Logic scan shows Error bit set for the [ARD] instruction. I am assuming this is because the instruction updates Asynchronous to the logic scan. However when in this state, the [ARD] may or may not operate.
I.e. seems to get stuck in an unknown state and no data is grabbed again from the buffer.
If it hangs, I can get it to go again by going in to Tag Data monitor and manually toggling the run (.RN) bit and it starts executing again.
My questions:
1. Why is ARD go in to an error state when an “ACL” clear buffer executes?
2. What’s the proper way to detect and recover a stuck “ARD” instruction?
3. When “AWT” instruction is sent (CMD to device), how long before buffer has the reply? (assuming 9600 baud comm’s) under 250ms for 150 Byte (ascii Characters) reply?
If Buffer is not cleared, logic executes perfectly and I have no problems with comm’s as long as I am only sending one command and the response to it is 150 bytes. But I need to be able to handle varying data length responses sent from the device for many different commands sent to it. Device does not use LF/CR or a common delimiter for all of the responses and some command replies can vary dynamically based on certain conditions. So I need to start with a fresh buffer each time a new command is sent to the device so I can handle the input appropriately.
The comms between the PLC and Device are Synchronous and PLC is the Master.
Thanks