Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Zero Magnitude on March 22, 2018, 12:37:33 PM
-
What's the bare minimum code to read data from a serial port?
Edit for answer: STREAMIN is the only block required.
Setting up the port and checking the hardware layer is best done outside the ladder logic.
---
I've looked at the example IntSerial server port code, and it seems like complete overkill for what I want to do.
The plan is to read from a Honeywell linear sensor that puts out data at "RS-232-type digital" at 57.6kbits/s (The SPS-L225-HDLS (https://sensing.honeywell.com/SPS-L225-HDLS-smart-position-sensors-sps-series)). That is the sum total of all information I have on the sensor's communication and setup. The datasheets and specs don't tell me the part, bits, stop, etc. ¯\_(ツ)_/¯
The sensor has a 6-24V input, ground, and output. I've got 12V and ground hooked to the same PLC power, with additional ground pigtail to the IntSerial GND. The output wire is attached to the IntSerial RX/D- pin. Nothing is attached to the TX/D+ pin.
BRX is a BX-DM1-19ED2-D (https://www.automationdirect.com/adc/Shopping/Catalog/Programmable_Controllers/Do-more_Series_(BRX,_H2,_T1H)_PLCs_(Micro_Modular_-a-_Stackable)/BRX_Series_PLCs_(Stackable_Micro_Brick)/18_Point_Micro_PLC_Units_(BX_18-z-18E)/BX-DM1-18ED2-D)
All I'm looking for is simple code that reads in the info from the sensor. If I could get bad information, like if it's the wrong parity or whatever, I can use trial and error to find the right settings. All I'm getting is errors though, either with the sample code or with a couple of rungs that I've been trying. (SETUPSER, OPENDEV, DEVREAD, STREAMIN) and it feels like I'm just missing one step somewhere.
I can't find anything in the online documentation, the forums here or at AD, and I'm stuck. If there was even a way to read the error codes (instead of "Failure Detected") that would also be helpful.
-
I don't know if this is the correct way, but I always started rs232 projects with talking to a PC using a software like Putty or Hyperterminal.
-
It's been a long time since I've had a computer with a serial port.
I've got a USB / 232 cable on order but it's not here.
-
Sad, sad, sad. Went to the Honeywell site and could not find ANY details about THEIR product. Tried google. Nothing. I'm guessing that they want to sell you a "comm card" to talk to it?
Sad, sad, sad.
Hopefully somebody out there has some information about Honeywell. I think they are a big enough company that others have used their stuff? ;)
-
I'm still leaning towards "I have not got this coded correctly" vs. "Honeywell is to blame". ;)
I'm now getting "Attempted operation not supported by device in STREAMIN" which is weird, because isn't STREAMIN the only way to get data out of the RS-232 stream?
-
You probably don't need the OPENDEV or DEVREAD. Definitely get rid of the OPENDEV. That's only useful if you need to dynamically change your serial ports at runtime (e.g. sometimes I want to use the IntSerial, sometimes SERIO port A, sometimes SERIO port C).
If you are going to use DEVWRITE, make sure you are waiting for it to finish (see the On Success bit) before you try to do a STREAMIN or STREAMOUT.
The serial port needs to be configured in the System Configuration as "Program Control" (aka ASCII, using STREAMIN/STREAMOUT). Make sure that is written to the PLC.
-
Also, don't forget to change your STREAMIN to use @IntSerial, NOT the Device Reference from your OPENDEV instruction, which is not needed.
-
Thanks, that's definitely an improvement!
I'm now seeing the number of messages in the queue increasing in response to me wiggling on the sensor, but I'm not seeing the data come out. Once IntSerial.InQueue gets to 1023, that sticks there until I power cycle the PLC.
I'm trying both reading to a string and reading to a D location.
-
Post your STREAMIN rung. Either a screen shot or copy/paste the mnemonics (select the STREAMIN rung using Shift+DownArrow key, then do Ctrl+C, then paste the clip as text here, removing all the SYSCONFIG section stuff)
-
Do you mean this?
// Ver(103) PCU(3) Do-more Designer Clip Source Project: Format: Do-more Designer 2.00+ DO-MORE Ladder PLC BX-DM1-18ED2-D
STRGT IntSerial.InQueue 0
AND C0
STREAMIN @IntSerial 2 0x0 100 0x0 SS0 DST511 DST511 DST511 0x0 0x0 C4 C5
C0 is the OPENDEV success flag. It's programmed to open with a switch so I have time to pick up the sensor after hitting run.
I put the SETUPSER back so I could easily modify the settings without the warning. I'm not really sure what the settings for the sensor are, so I'm running through the 12 cases.
-
It appears that your device is probably just broadcasting characters, and you have filled up your serial port buffer.
You will be spinning your wheels if you just keep cycling through various parity/start/stop bits using SETUPSER before every STREAMIN. Try to figure out what it actually is (pause between each one for 3 seconds). Then set it up statically in the System Configuration.
Trust me, nail that down first before thinking you have a "logic" problem with your STREAMIN. You may still have some STREAMIN issues, but until you nail down the physical layer, the code ain't gonna work.
-
I don't know if this is the correct way, but I always started rs232 projects with talking to a PC using a software like Putty or Hyperterminal.
Yeah, what he said. I remember some terminal programs (not sure which ones) will autobaud, which hopefully means they'll automagically detect the port settings as well. N81 and 7E1 are both very commonly used configurations. If you have to go by trial and error, I'd try those, and possibly O81 first.
-
Okay, there's now one rung of code total, it's the STREAMIN block. When I play with the sensor, the input buffer counter increases and the RX light goes on. I guess it's 8/1/N?
How can I reset the buffer, and how can I get data (even bad data) out of the buffer? SS0 doesn't change at all.
// Ver(103) PCU(3) Do-more Designer Clip Source Project: Format: Do-more Designer 2.00+ DO-MORE Ladder PLC BX-DM1-18ED2-D
STRGT IntSerial.InQueue 0
STREAMIN @IntSerial 1024 0x0 100 0x0 SS0 DST511 DST511 DST511 0x0 0x0 C4 C5
No computers here have a serial port. I can not possibly connect the PLC to a serial port.
-
DEVCLEAR
-
Ah, well now I have garbage coming in!
It looks like if the buffer is zero, the PLC will read garbage but if if the buffer has anything in it it'll jam and not read anything until .inqueue gets reset, and then it'll read [some number] of garbage packets until it jams, then .inqueue will increase until it gets reset again.
So are there things I have to code in to get the data to go from buffer to a string / D location that aren't part of the STREAMIN block? Do I have to manually put in the DEVCLEAR box when it reads a packet? Do I have to wait for a flag to be set before I read the stream?
-
Ah, another update.
The sensor isn't actually RS-232 -- despite the manual, it's at TTL levels (0-5V)! So although it's technically running at 8/1/E, the RS-232 port on the BRX can't read high from low when the output is right on the edge of acceptable. (From what I can see, the minimum swing on the BRX is 0-5V, so even a slight drop is going to be enough to go from "high" to "unknown"). That explains why the graphs are showing garbage, because all the data IS garbage. (5V max and 5V minimum only has a ~50% chance of working, and 0% chance of being reliable.)
So next is finding an RS-232 / TTL converter. At least those are OTS.
The digital output RS232 is encoded at 0-5V signal levels so a TTL to RS232 level shifter is likely required for directly connected RS232 signals.
The digital position output is in two 8-bit bytes, high-order byte first.
Each byte is constructed as, 1 start bit, 8 data bits, 1 even parity bit & 1 stop bit.
The answer to my initial question is "the only block required is STREAMIN", as long as the hardware layer is set up correctly.
-
on the programming side, I am generally a fan of waiting in a stage until .InQueue contains what you expect, then jumping to a read stage where you read a specified length or delimited data, then jumping to a processing stage, then back to the wait stage. It seems heavy perhaps, but it's bullet proof that way.
-
So how would that look? I know that a lot of the ASCII handling blocks contain stage jumps on success / failure.
-
Create a program block that just handles your data stream. Don't know whether your frames are fixed length or delimited. If fixed length, just wait for and read that length. If they are delimited, wait for the minimum it could be, then stick a timeout on the STREAMIN a bit more than what the worst case transmission time is on the largest frame. I didn't put any retry code in the error, but I would normally do a DEVCLEAR, bump a count, and jump back to the top stage...no need to exit.
-
And of course your processing will likely be more interesting than a STR2INT, but hopefully you get the picture.
-
Ah, that's exactly what the code required, thank you. I am just streaming the number directly into a D-location, and then a little math to get the linear position from the 4000 - 60000 raw byte data.
This sensor DID require a level converter, so once that got soldered up it's working great. Only one wire (plus power lines, obviously) is required to get this particular sensor working.
-
Another thing you might want to consider is adding a stage at the top that reframes. If the samples are coming at a particular rate, say 1 per second, there is an expected bit silence prior to the sample. Basically you want to sit in the reframe state until the line has been silent for 500ms (based on the 1 second rate above), and then jump to the wait state after silence. Without a reframe stage, you can get out of sequence and never recover.
So basically:
Reframe Stage
If .InQueue != 0
Tmr.Acc = 0
Jump ClearQueue Stage
If Tmr.Acc > 500ms
Jump to Wait Stage
ClearQueue Stage
DEVCLEAR with a jump to Reframe Stage on Success
-
Once I added the reframe code, I would also have the Error Stage jump back to reframe.
-
The pause interval seems to be only 3ms and that's implemented, but it's all gone haywire over lunch (before the reframe add-on).
I don't know what happened. I imported the test code into the main code, it didn't work, and then I couldn't get the test code to work again.
-
A couple of things that might help you debug:
1. You can halt/run/enable/disable programs, tasks, and stages from the Project Browser. Right click on the code item and select Debug Code-Block.
2. Cycling to program mode will reset all programs and tasks, but power cycling does not (for blocks marked retentive anyway). If the code is off kilter due to some of your code changes, you might need to cycle the mode.
3. The Project Browser shows stage status if status is enabled for that view. Very useful for following sequence flow. If you have assigned nicknames to your stage bits, it makes it even easier to follow.
So your device just spits out un-delimited data with only a 3ms framing window? That's pretty tight.
-
Yeah, it's pretty tight. I'll definitely order the 0-5V output for production instead of the RS-232-ish, but it was a sample so I'll deal with it for prototyping.
I think the issue is on the hardware layer rather than in programming. The data tends to come in weird every now and then, and the reframing window must be wrong because that just makes it worse. They've provided some oscilloscope outputs, but the data in there is pretty tough to parse. I think it's supposed to be their internal engineering info.
-
Can it be configured to use some form of delimiter?
You might also be able to get creative with high speed I/O to measure the silence, but this is a deceptively difficult thing to make 100% bulletproof.
-
It's got three wires: power, ground, and out. Other than that, it's IP65 sealed throughout.
I can't imagine a scenario where rolling my own high-speed I/O RS-232 auto-gap detection system would have any kind of reliability, and the time spent on it, dollars-wise, would be better spent just buying the analog version. :D