BRX -> Internal Serial -> read-only sensor

[Zero Magnitude]

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.

[BobO]

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.

[Zero Magnitude]

So how would that look?  I know that a lot of the ASCII handling blocks contain stage jumps on success / failure.

[BobO]

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.

[BobO]

And of course your processing will likely be more interesting than a STR2INT, but hopefully you get the picture.

[Zero Magnitude]

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. 

[BobO]

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

[BobO]

Once I added the reframe code, I would also have the Error Stage jump back to reframe.

[Zero Magnitude]

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. 

[BobO]

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.

[Zero Magnitude]

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.   

[BobO]

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.

[Zero Magnitude]

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.