Can't get modbus working on new LinuxCNC box

Have been using a Dell with 2.7 under Preempt-RT and a hitachi X200 vfd on a built-in RS232 going through an isolated RS232-modbus bridge.  This was originally the wj200_vfd code, I changed a few lines to work on the x200.  Been working for years.

I'm changing to a fanless NUC with a built-in RS232 port, 2.8 under Debian.

I had  a ton of trouble figuring out how to compile the vfd code again, but it looks compiled.  LinuxCNC runs, but then Modbus just times out.  I'm at a loss what it's doing.  Launched putty terminal, shorted TX & RX, that echoes back.  It's definitely ttyS0.  Found a PL2303 cable ending in a DB9 that should be RS232 levels and changed to ttyUSB0, but still timed out.  The code is being told the correct baud rate, and I changed the code default to the needed baud rate too.

I did think about it and if the TX path worked, it would still respond to the spindle start command, so I'm guessing it's not doing TX.  I'll bring in an oscilloscope soon.

Any idea what could be wrong?  

Is the user member oft the dialout group?
 

Hmm, I hadn't heard of this. I'll test it out when I go to the shop.

But it's only got one account on it, and I know I used that account to putty some characters across in a loopback. If the user didn't have dialout, that would have failed, right?

That should be OK then.  I had also changing  ttyUSB0 and ttyUSB1 when pulling the USB and putting it in again.

I remember I had a hard time to configure the command to 
connect to the vfd.(huanyang)
Not at the mill right now, so I can't look up the halcommand ...

 

OK, I really should have done this earlier.

I am seeing valid RS232 at the target 19200 baud coming out of ttyS0.

I looked on the Modbus bridge (differential, single duplex) - I saw UART traffic of two somewhat different levels, which I presume is because one level is the response from the VFD.

I don't have a DB9 breakout box to confirm it was getting that communication back. We do know the ttyS0's RS232 transceiver works since it did that putty terminal loopback ok. I don't see how the Modbus-RS232 bridge would screw up the return traffic since it works fine for the old LinuxCNC installed on the old PC.

I wanted to just launch putty to read the vfd messages, but it's a slave. Without LinuxCNC initiating transactions, I don't think it spontaneously sends status packets out.

Where's the source code for the libmodbus on this PC going to be? I did the automated get-and-install, but I'd like to modify it a bit to inject some new debugging messages that might shed some light on where it's being dropped. But I couldn't find it anywhere.

You are running a RS232 to RS485 converter?
Have you terminated the bus and also set the bias? Sometimes something like this helps:
en.m.wikipedia.org/wiki/File:Rs485-bias-termination.svg

Funny you should mention that. The X200 only has 485 P/N pins, no ground, on the RJ45 or anywhere else.
I was never comfortable with that, I like to tie together grounds. And it does lose connection and timeout briefly during spin up/down but otherwise worked fine.

In the absence of a ground, with both devices having floating grounds, the X200 will presumably have a bias network to float the relationship into a usable range. Again, not my sensibilities, but Hitachi definitely put P/N on the RJ45 and says all other pins are "do not use" and nowhere else offers a ground for the DC logic here. I've got to assume Hitachi knows their RS485 and this should be ok.

Anyways, it still works with the old PC- we're just changing the RS232 side, the VFD, 485 cable, and 485 converter don't get touched when switching to the new NUC box.

One notable thing I can think of is the NUC isn't earth grounded AFAIK, as it runs on a DC wall wart. But unlike the VFD's 485 cable, the RS232 cable wires together the RS232-485 converter's RS232 side to the NUC's RS232 port ground.

So, NUC and RS232 are tied to each other but the net has no relation to earth ground, which still seems ok. I think earth ground would just add noise.

Okay if you cant access the GND and VCC of the VFD then this will not ne applicable.
I only remeber  a servo drive where I had to add a bias network to get it working (with a two wire connection).