ControlLogix to read in Serial Data over RS232

"Thank you! My brother converted it to a PDF and I am reading it.


It is quite the Magnum Opus.

I have one question (so far) about that TOF delay before the read: how is putting the 2s of delay before the read any different, functionally, from adding 2s to the timeout after the read?"

Click to expand...

This 2 second TOF delay before the Read Command allows sufficient time for the Met4A because the P9 command contains a request for a pressure reading as well as other transmitter data and the WeatherStation takes a pressure sample.

Taking a pressure sample takes a small amount of time to comlpete. Without that time delay for the read statement I was only getting partial data back from the Met4A WeatherStation or sometimes nothing back at all.

It was a fun troubleshooting session haha. I could make all sorts of requests successfully but any time I wanted barometric pressure data (there are other commands besides the P9 command that I tried) the data never came through and I believe if I remember correctly the Read instruction actually error'd out sometimes. I thought about why and then it dawned on me that taking a sample probably meant it needed more time. So after adding a TOF delay I was successfully able to get data every time.

The delay after the Read that is part of the Timeout is probably something that Ken can explain better. From my understanding of how it is working, I needed that timeout in order to reset the Command and Read so that they would go out and repeat the process to acquire new data. When I removed that timeout logic my Command and Read only happened once and then the .DN bits were set and never cleared. I think this is because the ASCII clear buffer was no longer getting cleared.
Why there is a timer there for the timeout I think has to do with the timeout in particular but I can't explain why at this point. I know I am missing something regarding more functionality of the timeout but I have honestly never used a timeout before and my experience in this area of serial communication is still pretty limited. Ken added that in the first copy that was posted and it was exactly what I needed to continue polling data after it was successfully received.

blanchsb1 said:

This 2 second TOF delay before the Read Command allows sufficient time for the Met4A because the P9 command contains a request for a pressure reading as well as other transmitter data and the WeatherStation takes a pressure sample. ...

Click to expand...

Thanks for the explanation.


It seems odd to me that a read, which I think of as a passive action, would not simply sit there for the two seconds or however long it takes for the Met4A to complete the pressure reading and start sending data back* - because those data are going to be sent, and we know that because the write requesting those data completed


* assuming no out-of-band events like a bad cable or the Met4A gets shut off or whatever



Did you look at the ABL command as an alternative to the timeout? That would be triggered by the write .DN bit, wait for a response, as indicated by the termination characters, to be in the character buffer, and then the ABL .DN would trigger the ARL to read them. AFAICT it amounts to a poll, and because the ABL is checking (examining?) the buffer and not reading from it, it won't affect what is eventually read by the ARL. Even if the returned message was longer than the buffer, so the the ABL could not check for the termination characters per se, it could set its .DN bit on some other "termination" character that would occur earlier in the returned message, at which point triggering the ARL would work because the rest of the message would be following shortly.



I am not saying the delay TOF is wrong (if it ain't broke ...), just wondering about the resulting behavior and if the pieces already have a designed way to solve the issue. Timers always seem so brittle and need to be tuned to the specific message: too short and you don't get the desired effect; too long and maybe a buffer overflows. I would get more warm fuzzies with an alternative that does not need tuning.


For example, I am fairly certain that if I ever connected a PC serial port to an Met4A, then whenever I wrote that '*0100P9$R$L' request, I could start the serial read immediately after and simply wait for the data, as long I set the read timeout large enough. I have done that with many and various pieces of equipment; I realize the PLC is not a PC, so this thread is extremely useful to me to learn about the former.


Again, thanks for following up on this thread and supplying your program; it has been and will be a great learning experience for me. I apologize if I have taken too much time out of your day.

Thanks drbitboy. I have not used an ABL command. I will research it and get back. I agree that timers are "brittle", just how I have been trained in my company, "just throw a timer on everything and adjust as necessary", haha.

It doesn't mean it is the most elegant way to do things but it is a way. I'm all for spreading my wings some more on this project. I hasn't been installed yet so I have a little time to play. I'll check and post back about it.

Also, Ken I actually have a 1756-EN2TXT (yes it has a giant heat sink and is just the extended temp model). I must have been tired when I posted before. My company upgraded to those a couple of years back and our internal "parts" department exclusively uses them. So this supports sockets (not sure about how those work exactly but I am up for more learning).

blanchsb1 said:

I agree that timers are "brittle", just how I have been trained in my company, "just throw a timer on everything and adjust as necessary", haha.

Click to expand...

Yes, and TBH I have to admit to writing my share of timer-driven processes; sometimes nothing else will work.


"haha" <= exactly!

I am not sure if this thread is still alive but I will give it a try. I am working on an IVEK pump and trying to communicate to it via PLC (1769-L24ER-QB1 + 1769-ASCII module). I can't get it to work and I thought maybe I could use this as an example. Unfortunately, once I import the solution routes from this thread I can't get the AWA/ARL/ACL instructions. I am assuming it's because the example code is coming from the PLC with embedded serial comms. How could I change it to accommodate my differences?

blanchsb1 said:

I am using an Allen Bradley ControlLogix PLC (Logix5561) RSLOGIX5000 version 20.04.

I would like to communicate with a Paroscientific Met4A weather station and store the requested read data in an array in the PLC.
The links to the 2 user manuals are provided here on Paroscientific's website:
http://paroscientific.com/pdf/8819-001_Digiquartz_Operations_Manual_for_RS_485_RS_232_Products_715_Display.pdf

http://paroscientific.com/pdf/8008-001_Manual_for_MET4_and_MET4A_Meteorological_Measurement_Systems.pdf

The Met4A allows for communication on RS232 or RS485. I already have a cable and adapter to communicate over RS232 set up that also powers the Met4A device and has a 9 pin connector (DB9)

Based on what I have read from the manual. It looks like this is serial communication using ASCII Serial Protocol. Is this the same as Modbus ASCII protocol? The commands and responses are different than how I understand doing modbus comms using Modbus RTU.

Example from the Manual on how to read a parametr's value of a tag named UN:
Command:
*0100UNCrLf
Response:
*0001UN=1CrLf

Is it possible to communicate with this using Prosoft's Modbus Module? Currently I have a Prosoft MVI56-MCM module for Serial Modbus RS232/RS422/RS485.

I am just unsure about the mapping and how I go about requesting to read the data.

I am novice at modbus comms, but I have gotten Modbus RTU comms to work using modbus RTU in RSLOGIX and the Prosoft AddOn import logic for talking with other hardware. But I am not as familiar with ASCII and whether this can be done with my PLC and Prosoft module.

Or do I need additional hardware?

At the end of the day I want to get this Met4A data into my PLC and I don't really care how. My company can buy another module or other hardware to read it in if I can prove it works.

Thanks in advance.

Click to expand...