Hi there, I’ve been working with the RS-232 protocol using the AXL RS UNI 1H communication module and AXL RSUNI PD function block to stream weight data from a scale. The controller used for this project is the AXL F 1152. The DTR and CTS inputs have been shorted together on the module and the transparent protocol selected in software. I’ve had no trouble sending and receiving data but found that the receive array is sometimes filled with zeros for multiple program cycles before the modules buffer fills it with new data (the program exists in a single idle task). I thought that it may be the way I had programmed the send and receive algorithm and tried multiple variations, I’ve also tried various baud rates - neither solved the problem. I then noticed that this also occurs approx 1/5th of the time when I manually toggling the send and receive bits of the function block. While I am getting data, every cycle that a 0 is present is a cycle where other parts of the program cannot react to any change in weight from the scale. Wondering if anyone has any insight or thoughts on this. I’ve attached a video so you can see what I’ve described in action, please let me know if there’s any other information I can provide.
Hi, I can’t see from the video how you are using the xRcvNDR output parameter, or more specifically the rec_done variable that it’s connected to. You should be detecting a rising edge on rec_done and, on that rising edge, arrRcvData (rec_array) will contain exactly uRcvDataLength (rec_length) bytes of data that were received by the RS UNI module. I am not sure if the contents of arrRcvData are defined on any other scan cycle, i.e. when there is no positive edge on xRcvNDR. You could try moving the contents of the array to a String (for example), or to another suitable data type, on the rising edge. Then, it doesn’t matter what appears in the array at any other time. Hope this helps. ~ Martin.
Thanks for the input Martin. I’ve attached another video with some logic next to the function block to show how I’m receiving data. The watches table shows part of the rec_array, my weigh scales value (scale_value), and the number of times its updated in 10 seconds (number_of_scans) by incrementing that integer every time rec_done goes high. By only allowing the scale_value calculation to occur on the rising edge of the rec_done variable the scale_value variable always stays stable. However it is the transmission rate which is the real issue. I have Tv set to 50ms in the video below and the scale has a transmission rate of up to 20 times/second which I have achieved with other controllers. Adjusting Tv to 250ms results in approx. 25-30 scale_value updates in 10 seconds which although is a decrease does not proportionally line up. The transmission rate seems to be lagging due to the array filling with zeros before updating to a new value. Its also important to note again that it doesn’t always fill with 0s before receiving the new buffered data. I’ve also observed no real pattern to this behaviour. It feels like there may be something I’m missing. Wondering if you have any other thoughts or different solutions to streaming this data more effectively. Incase you can think of an applcation, I should note that the scale does have the ability to constant stream its data without being requested every time. Thanks again, Alex.
Hi Alex, The Function Block being used here communicates with the RS UNI module using a protocol that is defined in the User Manual for the RS UNI, which can be downloaded from our website (I have also attached it here). The RS UNI can only be sent one command from the PLC on every Task scan cycle - e.g. send, or receive - and the RS UNI can only reply to the PLC with a maximum of 17 bytes of message data, so messages longer than 17 bytes will take a few scan cycles to be sent. These details are hidden by the Function Block being used here, but they might help to explain the timing that you are seeing. It is possible for the RS UNI to receive unsolicited data - i.e. to receive data from a Serial device without sending it a request. But (I think) the PLC will need to request the messages from the RS UNI at a faster rate than they are being received from the serial device, so you might need to start with a slower rate and ramp up. To get the PLC to request messages as fast as possible from the RS UNI, you could disable the Timeout (i.e. set tTimeout to T#0ms), and re-set the “Receive” request as soon as you get new data (e.g. set xReceive to the inverse of xRcvNDR). You can also set the Task Interval to be very low (e.g. 10ms), so that data is exchanged between the PLC and the RS UNI up to 100 times every second. There would then be no need (I think) to send data from the RS UNI to the serial device, which would save more time. If the serial device is sending data 20 times per second, then that gives us 5 x 10ms scan cycles to request and receive each message in the PLC. That might be borderline, but it might be good enough. If that doesn’t work, you could try reducing the Task Interval to 5ms, which would give 10 scan cycles to request and receive each message from the serial device. Hope this helps. ~ Martin.