As we say in Australia… Yeah, Nah.
The USB adapter drivers (like the wifi usb adapters) are not the same between the two platforms. More USB to serial adapters will work on the RIO than on the EPIC. Reason? The EPIC Linux is very different from the RIO Linux (more to say about this in the many months to come).
OK…Back in the Batcave now (i.e. my basement) and hooked up spare Rio with the SAME cheapie 9-pin to USB adapters and – as Ben predicted – the results are not the same as the EPIC. Plugging in either displays this:
I realized on my drive home that all I really want to accomplish at this point is using Node-RED to read my serial data, which was answered in this thread already. On the EPIC, I really don’t need the 9-pin to USB adapter…it must have been the 8-week hiatus that got me going down another path.
Thanks again guys!
PS: Also cancelled my order with Amazon for the other USB adapters (thanks Philip)
OK, almost there! (long story…I ended up changing to a Rice Lake weigh indicator and then had to fiddle with getting the Serial data out of that)
I have my scale weight being captured via Node-RED and sent via the TCP node per Philip’s suggestion:
And then in PAC Control, I rewrote some blocks from my existing program (where I was getting string data and converting to a float), to allow to obtain the data from the new Communication Handle. I can see the stream of RS232 data (50.27, 50.27, 50.27), but it gets chopped down to 50.2 (instead of 50.27) via the block shown. I have changed the 4 to a 5 and get no different result, so I must be doing something wrong?
Thanks in advance.
What is the length of Four_Digit_String_of_Weight? - maybe it needs to be Five_Digit_String_of_Weight.
Bingo. Thank you. It has been a few years since I went thru this program block-by-block.
And the finished product (middle panel is via MQTT)
Really appreciate the help!
Back to the subject of using the GRV-CSERI-4 EPIC module to read RS232 scale data, I am experiencing something unusual…
When I read (in Node-RED) the serial data from scale A, it comes across fine as a 17-character string. I parse the string using several change nodes to get the weight I want (7.0 lbs in this screenshot)…
Scale B also comes across as a 17-character string, though slightly different format. Again, after parsing the string using a change node, I get the correct weight of 16.1 lbs…
However, once I start running two different serial nodes at the time time, I get a different format. For example, I expect this:
But once I deploy both serial nodes (each configured to grab from a different channel / serial port of the CSERI), I get this:
So I can only conclude that there is something in Node-RED that gets confused when two different serial ports are sending data to the same flow?
FWIW, here are my serial node settings:
Scale A:
Scale B:
I have not seen anything like that here, but would need to try and set up a bit of a different test I suspect.
Are you able to share a screen shot of your flow around the serial nodes?
Here “scale A”
and here is “scale B”
When I disable one of them, the format changes, which in turn fouls up my change nodes to parse the data.
Update: I do not think this has anything to do with the CSERI or the serial-port node. I changed my settings to 7 data bits and 1 even parity bit and adjusted the other node-red serial port parameters from the manual (which I admittedly did not read prior to this…I just put 8, one and 1 and it seemingly worked). I will post an update once I have the rest figured out.
Update #2: It was definitely the RS232 scale output (not the CSERI or Node-RED) that was causing issues. Turns out there was a Start of Text (STX) character (0x2 in hex) that needed to be added, as well as adjustments to the parity, bits, etc. For a Mettler Toledo scale, this was the winning combination:
