#linuxcnc-devel Logs

Mar 23 2023

#linuxcnc-devel Calendar

02:53 AM rmu: andypugh: IMHO the level should not go down between time index 14 and 20
03:31 AM andypugh: rmu: That’s when the 7i96 RX stops driving
03:31 AM andypugh: Sorry, TX stops driving
03:47 AM rmu: bus should be in "idle" state then AFAIK, and not undriven/floating
03:47 AM rmu: the transition from floating to driven may be interpreted as start bit
03:49 AM rmu: https://www.ti.com/lit/an/slyt324/slyt324.pdf
03:56 AM -!- #linuxcnc-devel mode set to +v by ChanServ
05:35 AM andypugh: I can try with a VFD that I have. It was £20 from Amazon, I bought it to experiment with re-wiring the input stage as a voltage doubler. But it has A+ and B- terminals (and, completely un-mentioned by the manual, an 8P8C socket, which _might_ be modbus but of an unknown pinout.
05:40 AM rmu: andypugh: do you have those biasing resistors on the lines like pcw mentioned?
05:51 AM andypugh: Not yet. I am technically at work :-)
07:32 AM -!- #linuxcnc-devel mode set to +v by ChanServ
07:46 AM rmu: naming of rs422 wires is a bit strange. i would usually associate A with "+" and B with "-", and put 560ohms from +5 to A and 560 ohms from B to GND. it seems with mesa cards "+" and "-" is the other way round.
08:11 AM JT-Shop_ is now known as JT-Shop
08:11 AM -!- #linuxcnc-devel mode set to +v by ChanServ
08:49 AM andypugh: I will point out that this little relay board isn’t something that I want to use, it’s just a cheap test item to try to make a generic Modbus for the Mesa cards.
09:12 AM pcw--home: Yes, on Mesa cards + is the inverted signal (Matching the EIA RS-423 standard)
09:14 AM pcw--home: the un-inverted signal must idle high for standard async serial RS-485
11:45 AM andypugh: Is the issue here that the modbus board is not pulling up the line when it is trying to send?
11:46 AM andypugh: (My USB to Modbus dongle has no problem reading the data sent by the board, by the way)
11:51 AM pcw--home: No, the issue is that the 7I96 is really designed for high speed RS-422 so is terminated in the cable characteristic impedance to avoid reflections and doess not have sufficient local bias to force and idle level when not driven
11:55 AM pcw--home: That is what the added resistors are all about. Without this bias, both RX UARTs may see bogus start bits
12:02 PM pcw--home: (when neither side is transmitting)
12:56 PM andypugh: I have tried with resistors, no change
12:59 PM pcw--home: What is the idle state voltage?
01:08 PM andypugh: I have also tried to send to the 7i96 from the USB-serial using cutecom (a config which sucessfuly operates the relays on te board) but still see nothing
01:14 PM andypugh: 0V-TX- = 0.9V,0V-TX+ = 1.2V, 0V-RX-=0.9V, 0V-RX+=1.2V, Rx—Rx+= 0.3V, Tx—Tx+=0.3V
01:16 PM -!- #linuxcnc-devel mode set to +v by ChanServ
01:16 PM andypugh: Maybe I am setting the Rx registers up wrongly? Basically the read comands return exactly the same data even with nothing connected. I can alter what the errors and data are by changing the Rx frame delay. And also by setting Rx Mask bits differently.
01:24 PM pcw--home: it might need stiffer pullup/pulldowns (even as low as 100 Ohm)
01:27 PM pcw--home: getting the same thing with nothing connected does suggest the bias issue (or mismatched RX/TX baud rates)
01:29 PM andypugh: Should there be a 120R termination between Rx and Tx too?
01:32 PM pcw--home: Part of the issue is that for 9600 baud you probably don't really want termination at all because it interferes wit the idle state bias
01:32 PM pcw--home: with
01:34 PM pcw--home: this is why quite stiff pullup/pulldown resistors may be need to get a decent idle state voltage
01:34 PM andypugh: OK. If we ignore Tx for the moment (which is working) can I just connect the two wires from the USBserial to Rx- and Rx+ and the pull-up pull-down as described? (ie, ignore Tx for the moment)
01:34 PM andypugh: And what idle-state voltage should I be looking for?
01:40 PM pcw--home: 1V would rule this out as a problem (100 ohm pullup/pulldown should give almost 2V with violating the 50 ohm minimum RS-485 load resistance)
01:40 PM pcw--home: without
01:41 PM pcw--home: (that would end up at 75 Ohm differential load resistance)
02:07 PM pcw--home: also make sure 7I96 RX-/TX- (TB2:17,19) end up positive relative to 7I96 RX+/TX+ (TB2:16,18)
02:20 PM andypugh: Yes, the voltages are positive as described
02:21 PM andypugh: But still nothing.
02:21 PM andypugh: I wonder if there is any value in halscoping the pins?
02:21 PM andypugh: Anyway, I need to head out now.
02:22 PM andypugh: Back in a few hous.
07:29 PM pcw--home: I did find out the the 7i96_pktd.bit file is old enough that it does not support parity
07:29 PM andypugh: That’s not a problem, I don’t think, as I am not using parity.
07:30 PM andypugh: What does the frame delay setting actually do in the Rx?
07:31 PM pcw--home: it does matter if the relay card is sending parity
07:31 PM andypugh: No, the relay card is no parity.
07:32 PM andypugh: (There is a CRC in Modbus, so parity makes no sense)
07:33 PM pcw--home: Frame delay on RX is how many idle bit-times before it decides an RX frame is complete
07:39 PM pcw--home: probably 1 character time or so unless the sender is very slow between characters
07:39 PM pcw--home: is the relay board MODBUS protocol ASCII or RTU?
07:42 PM andypugh: RTU
07:42 PM pcw--home: OK
07:44 PM pcw--home: (ASCII with no parity would probably not work since is 9 bits total (1start+7data+1stop) and PktUART is always 8 bit data)
07:45 PM andypugh: I have the grame delay at 20 at the moment as that was mentioned in the regmap (though that would be for a much faster bitrate).
07:46 PM andypugh: I can try lower, but given that it seems to be “seeing” about 900 characters (about as many is can fit between polls, I think? I am polling once a second at the moment.
07:55 PM pcw--home: Are you sure the RX baud rate is correct?
07:56 PM pcw--home: not sure how else you can get hundreds of chars from a dozen or so
08:18 PM andypugh: It gets just as many chars if not even connected. Or with nothing sent to it.
08:19 PM pcw--home: "RTU mode messages start with a silent interval of at least 3.5 character times"
08:20 PM pcw--home: A biased but unconnected RX gets this?
08:21 PM pcw--home: if completely unconnected (no bias) that might be possible
08:23 PM pcw--home: halscoping the RX GPIO pin should show it always high if not driven (and biased properly)
08:25 PM andypugh: Well, yes and no. Bear in mind that I am just continuing after errors in the pkuart driver at the moment, trying to see if anything is getting through. It always sets the “no stop bit” error and by default the driver gives up at that point.
08:25 PM andypugh: I will try halscope tomorrow. It’s time to sleep here.
08:26 PM pcw--home: 'nite