ShapeShifter:
you need to add some delimiters to your data (simple new line characters may be enough in many cases) and then read the data a character at a time, buffering the data until the terminator is read. Then, when you get a complete buffer, you can try to parse it.
That sounds like it is the same concept as in the 2nd and 3rd examples in Serial Input Basics
Robin2:
That sounds like it is the same concept as in the 2nd and 3rd examples in Serial Input Basics
Yes, it is functionally the same as a serial interface - it just uses different hardware and a shared wire, but the resulting data streams (and loss of record cohesiveness) is the same. 8)
ShapeShifter:
Yes, it is functionally the same as a serial interface - it just uses different hardware and a shared wire, but the resulting data streams (and loss of record cohesiveness) is the same. 8)
I hope my code may give @zerox12 some useful ideas.
zerox12:
I will try this. In fact I have to try it because it turns out the Yun crashes when byte-compiling large files. I just found this out after installing pip and doing:
pip install -v freeopcua
It installs all the dependencies perfectly, then trys to byte compile a 1.3MB .py into .pyc and locks up, then drops the SSH connection. When I reconnect and do
pip freeze
only the dependencies got installed.
Thanks for the info.
FYI. The reason the Yun crashes is because byte compiling this module causes linux to run out of memory. I tried to run pip install on this module while the Console was open and as soon as it hit this file linux kills pip due to no memory.
If anyone is interested, Python Free OPC UA server does run on Raspberry Pi and Beaglebone Black.
It seems like people on this forum are particularly enamored with I2C - I don't understand it. My only thought is that they are typically hobbyists that don't have to design a robust system and don't mind having to periodically reset/cycle power to keep it running. Personally, I much prefer SPI: it takes an extra wire, but it's pretty much bullet proof. But I wouldn't use it to distribute sensors around an electrically noisy machine. Something like RS-485 is much better for that.
Can you expand on this? I've had no trouble opening a TCP stream port between a PC and a Yun and leaving it open for hours or days while talking in both directions with no special handshaking.
@ShapeShifter,
I2C are typically sold to robotics in the hobby industry. Now i know why I see so many bad robotics designs. I'm no EE, but your explanation is in plain English to me.
On the issue with the OP, I don't get. Right now we are talking about protocol design, which is good, but for what? All I know is we are looking to get respond time down to a few ms. To what end?
My question is: Can we accomplish the same goal with another method - possibly an easier method?
Anyway still don't have any answers to my questions.
FWIW: I'm only checking message that I have responded to OR messages that are over 24 hours old. I need to cut back my time on the forum. This seems to be working well.