Trigger a message payload based on input from parallel port

Dashboard
41

At a guess, the delimiter is incorrect. What delimiter (if any) do you have set in the serial in node.

If you post a copy of the devices serial protocol as @Colin suggested, it should tell you enough information to determine a good character to split on.

42

@Colin and @Steve-Mcl

This is the node so far:

[{"id":"23d339db.7bd296","type":"serial in","z":"71e9cb0c.6a3ff4","name":"Tape","serial":"14fa8305.476bfd","x":150,"y":80,"wires":[["e83aeb2c.91a178","9dde2cac.257cc","f649458d.777048"]]},{"id":"14fa8305.476bfd","type":"serial-port","z":"","serialport":"/dev/ttyUSB0","serialbaud":"9600","databits":"8","parity":"none","stopbits":"1","waitfor":"","newline":"9","bin":"false","out":"count","addchar":"","responsetimeout":"500"}]

I have a newline set to 9 that gives me the best results after tests. I did try to set the split for "/n" but I get more junk and inconsistency.

the input is a regular serial port that comes from an e-machine.
I am grabbing the data that goes to a tape machine. The codes are related to the length of the tape that the machine has to provide for each box.

The code comes from a web socket inside a web application (wish I could use that but hell no thank you https for screwing me).

I connect the raspberry pi thanks to an adapter:

067b:2303 Prolific Technology, Inc. PL2303 Serial Port
43

I would suggest you might want to mess around (if you can not get the info elsewhere) with different serial parameters - your speed looks right, but i would look at playing firstly with the number of stop bits 0,1,2 and then the flow control DTR, XON/XOFF, CTS/RTS and see if your hit rates improve

Craig

44

It is not the code that we need to see, but what the data from the device looks like, in full detail including if there are time gaps in the data. You may be able to use the timeout facility to detect the end of a sequence for example.

45

@Colin While I was trying to get more data for you guys I saw what was going on:

So as I told you before my serial0 was set to split the message into blocks of 9 characters because I wanted to get rid of the "@1T\n@XR\n@" that is shared for every box.

What I did not put into consideration is that some codes have 4 alphanumeric identities and some others have 5 (ex 1Y62... 1Y10...1Y0223)

so for each scan I was getting the right code but shifted because there was no consistency.

For example:
{ box code}
[ascii block size= 9]
{[@1T @1XR ] [@1Y10 }{@1T] [ 1XR @1Y1] [0 }{@1T @1X][R @1Y10} ]

so now I changed my settings for the parallel port to start after the character "@" and stop after 200 ms

And it works :smiley: