[NeoTech]

So this took a while to figure out before i realized what was going on.

Serial transfers are really robust and there is a reason for that back in the day, they tended to combine two protocols to make it really stable.

DC Code control and RTS.
So what is DC Code control.. Well its what we call Xon/Xoff these days. <DC1><DC3> commands.

Everyone that tries to set one of these up will run into the aggsoft page, that wants you to set Parameter bit register like this

12.0 (1 stop bit: yes) 0
12.1 (No ready sig.: none) 1
12.2 (Parity check: no) 0
12.3 (Even parity: 1 - even, 0 - odd) 1
12.4 (8 data bits: no) 0
12.5 (DC code: yes) 1
12.6 (DC code type 2: no) 0
12.7 (File name read: yes) 1

And that is great for a computer for example that can manage the DC Code at the same time as it runs RTS. Where it essentially uses the DC Codes for the handshaking signaling to start and stop.
But it uses RTS in the background on a hardware level to signal when its ready to send and receive.

Most "devices" these days does not implement the blended format where they use a Software flow control ontop of a Hardware throttle control (its easiest way of describing it).
You either have a device that can do Xon or RTS. And in my case that was true.. I decided to get a Moxa Nport 5110 - which is a Ethernet based Serial modem.
It can do RTS/CTS just fine and its stable - but it wont do Xon/Xoff handshake when it does. And if you flip it to Xon/Xoff it will handshake but never set the RTS signal high on the interface so the machine will never start receiveing.

The work around is the Bit register called #12, bit 5 - you change that DC Code: yes - to a No by setting it to 0.
This turns of the <DC1><DC3> handshaking and it will only rely on RTS.. What is the Caveats you say. Cuz there sure is some.

Now if you hit the read button to store something it will not nicely sit there and wait for 30s and when you start sending it will nicely and controlled allow you to read and write file to the controller.
Instead you will have to hit the read button it will instantly set itself ready to receive and you will need to within a second or two start the transmission of the file. This worked just well with both Cimco, NCedit and My custom software written for the Moxa device. (more on that later).

So if you have a USB Serial port that is usually not smart enough on a driver level to actually do both - this is the workaround or if you buy a DNC and cannot get it to work, most likely its because it cannot do the combined protocol.

For the moxa box i created this: https://github.com/NeoTech/moxa-cli
This is a rust client that can send and receive files - the serial port setting is configured on the moxa interface itself, and you will only communicate with a TcpStream to and from the moxa device.
In front of it is a super duper rudimentary webinterface - and the whole thing builds into a Docker container that you can run on your computer, your synology or wherever you have Docker.
If you dont wanna runt docker, you can compile the rust application using the rustup toolchain, install node manually and run it locally with npm start command. (I do recoommend a long running container instance tbh).

I do hope this a bit lenghty post around Serial communication in the OSP5000(M-L) controller will help somebody down the line. If i found a way to make the hardware do a combined protocol - i will prob. update this thread.

[Algirdas]

thanks for sharing the ideas. Working with RS232 and RS485 since 1991 and still have something to learn about it