#linuxcnc-devel Logs

Mar 24 2023

03:51 AM rmu: i have modbus devices that communicate with modbus rtu 9600bps 8e1 i.e. 8 data bits even parity one stop bit
03:59 AM rmu: "smart" electricity meter
04:49 AM JT-Cave1 is now known as JT-Cave
04:54 AM -!- #linuxcnc-devel mode set to +v by ChanServ
06:36 AM -!- #linuxcnc-devel mode set to +v by ChanServ
07:08 AM JT-Cave: I've installed debian so many times it only takes me 30 minutes to get everything setup
07:38 AM JT-Cave: it's been so long putzing with the internet and pc issues I forgot where I'm at with mesact2...
07:50 AM JT-Cave: oh yea the spindle section
09:29 AM JT-Shop_ is now known as JT-Shop
09:29 AM -!- #linuxcnc-devel mode set to +v by ChanServ
01:11 PM andypugh: pcw--home: Quick polarity check. With the terminal block disconnected from the 7i96, with the USB-serial converter connected only to the Rx terminals, 16/Rx+ to 17/Rx- is +3.5V (that’s with the black multimeter probe on Rx+ and red on Rx-). With the plug plugged in to the 7i96 the polarity stays the same but the voltage drops to 0.3V (this is witout the pull-up /down resistors. Does that suggest that I have
01:11 PM andypugh: USBSerial wires the correct way round?
01:18 PM pcw--home: That sounds backwards, the 7I96 RX- lead should idle positive relative to 7I96 RX+
01:19 PM andypugh: That’s what I am saying, isn’t it?
01:20 PM pcw--home: OK Yes that sounds right
01:20 PM andypugh: Did you see my email? It looks like the data actually gets to the FPGA pin
01:21 PM pcw--home: As far are reading the data goes it must be done it two successive read functions (first reads the frame/byte count, second reads the data)
01:24 PM pcw--home: (the read can combine reading data from the last status read with a new status read)
01:25 PM andypugh: I can try exiting if it shows no frames, rather than carrying on regardless to see what is in the registers, if that might be causing a problem. But I basically always see exactly the same number in the mode register regardless (and that ends in an “E” indicating overrun.
01:27 PM pcw--home: Did you take a look at that sample program? it works on the same 7i96 firmware that you have
01:29 PM andypugh: Welll, I looked at it, but don’t have a pascal compiler.
01:31 PM pcw--home: If you ever read frame data that's not there, all future frame data will be invalid
01:32 PM andypugh: I can try the same register values. I see that you don’t have the Rx Mask active, which makes sense for a loopback test?
01:32 PM pcw--home: yes its a RS-422 lookback test
01:34 PM andypugh: OK, need to go shopping now, but will be back on this this evening. I wasn’t expecting getting the comms working to be any kind of problem, as I thought that pktgyro_test worked.
01:40 PM pcw--home: Yeah, if you get lots of chars on a fully idle RX UART (bias the 7I96S RX lines properly to guarantee) that suggests the driver is reading data when 0 frames or 0 bytes are available
03:03 PM andypugh: Well, I am only reading the number that it claims to have…
03:03 PM linuxcnc-build2: Build [#630](http://buildbot2.highlab.com/buildbot/#builders/14/builds/630) of `10-rip.debian-10-buster-rtpreempt-amd64` 4failed.
03:04 PM linuxcnc-build2: Build [#630](http://buildbot2.highlab.com/buildbot/#builders/7/builds/630) of `10-rip.debian-11-bullseye-rtpreempt-amd64` 4failed.
03:06 PM pcw--home: did you reset the RX UART after setup be before first use?
03:09 PM andypugh: Hmm… Actually, no. I think the driver does the reset first. Which is silly.
03:10 PM andypugh: Yeah, it resets the UART _then_ sets it up. That’s an easy thing to try to rearrange.
03:10 PM andypugh: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/pktuart.c#L166
05:23 PM andypugh: I am starting to think that I am wasting my time on this (and it’s a _lot_ of time now) . It just doesn’t make
05:23 PM andypugh: sense
05:28 PM andypugh: And I am also starting to worry about if it is possible to combine the UART with a normal thread. Is it allowable to send extra UDP packets separately from the main read/write threads?
05:28 PM andypugh: The reason I ask is because I am getting watchdog bites if the Rx Delay is less than 20 bits.
05:30 PM pcw--home: Everything must be in the normal read/write functions (so read data that requires changed behaviour of a subsequent read must wait for the next read function call)
05:33 PM pcw--home: http://freeby.mesanet.com/mfscript
05:33 PM pcw--home: is a little mesaflash script that tests 7I96 pktuart loopback at 9600 baud
05:37 PM pcw--home: (sends and receives 7 characters)
06:02 PM pcw--home: I thing to avoid all FIFO errors you must check for frames available in the RX mode register in one read function then on the next read function, read the data count FIFO and on the next, read the actual data
06:05 PM pcw--home: so poll frames available every servo thread, if >0 read the data count(s) on the next thread invocation and then read the data from the frames on the third
06:34 PM andypugh: What if I don’t run the normal read/write functions?
06:35 PM andypugh: PktUart uses the low-level IO functions to read/write registers.
06:35 PM andypugh: Anyway, I have tried that, it was exactly the same.
06:37 PM andypugh: Regardless of bitrate, or whether I use the 5i25 or the 7i96, whether it is a normal or RS422 port or whether I run the normal read/write functions or not:
06:38 PM andypugh: If the Rx Frame delay is > 10 then I get 0 frames of 0 bytes. And the 7800 port reads xxxx8E
06:38 PM andypugh: If the Rx frame delay is < 10 then I get 1 frame of 16 bytes, always read consistent data and the 7800 port reads xxx9E
06:39 PM andypugh: So I have error bits in all cases.
06:39 PM andypugh: Oh, and this is regardless of whether anything is plugged into the port, or whether any data is being sent to the port.
06:48 PM pcw--home: did you try that script?
06:52 PM pcw--home: (the script has 40 bit-times (4 char times) for xmit and 20 (2 char times) for recv)
07:28 PM andypugh: Not yet, I am working at a PC upstairs that doesn’t have the IRC on it.
07:30 PM andypugh: That script uses the DDR, I assume that isn’t strictly necessary to actually get data out?
07:36 PM andypugh: pcw--home: Have you done any testing other than loopback? eg 7i96 talking to 7i96?
08:08 PM pcw--home: Yes, in fact PktUARTs are used in FPGA sserial remotes like the 7I90 and the 7IA0
08:11 PM andypugh: You can maybe tell that after a week I am starting to feel rather disgruntled…
08:12 PM andypugh: I will try feeding data into the existing pktgyro_test component from the USB.
08:12 PM andypugh: But I have never _not_ seen the overrun bit set.
08:13 PM andypugh: I will try that script and see.
08:13 PM pcw--home: Yeah, didn't expect RX to be such an issue
08:14 PM andypugh: combining the uart with the TRAM (which isn’t TRAM) can’t be done, as that is a fixed list of registers that are read every time.
08:14 PM andypugh: There is no way to make a different number of reads (espacially zero reads) on different thread invocations.
08:18 PM pcw--home: I thought you could enqueue additional reads
08:19 PM pcw--home: otherwise FIFO access is impossible or really awkward
08:19 PM andypugh: I would need to look in detail, but as far as I recall we set up the “TRAM” reads in the setup code and then it happens every thread
08:20 PM andypugh: I don’t think we have any FIFOs at the moment?
08:21 PM andypugh: Not in code hm2. The 7i65 driver is a separate component using llio read/write
08:22 PM pcw--home: possibly the llio ops are queued on Ethernet
08:24 PM andypugh: The “TRAM” was set up by Seb (but never actually implemented) to use the Mesa TRAM system. I think that is a fixed table ot read/writes mapped onto contiguous registers?
08:26 PM pcw--home: Yes, it was designed for DMA scatter/gather block transfers
08:27 PM andypugh: So, we can’t fit FIFOs into that if we want to ever consider actually making “TRAM” == TRAM.
08:28 PM andypugh: But, if we give up on that, maybe we could, but I would have to go fairly deep into the driver code.
08:38 PM pcw--home: I'm not sure but I don't thing conditional things like parameter writes cause an independent packet creation/read so llio read/write may just get enqueued like tram stuff
08:38 PM pcw--home: I don't think
08:52 PM andypugh: Ah, yes, I need to look. I was thinking that they happened on-demand but thet might not be right.
08:55 PM andypugh: We do know that the writes go out, I have operated hardware. And the 7i55 driver works. I don’t think that there are any impossibilities waiting to trip me up.
10:50 PM linuxcnc-build2: Build [#631](http://buildbot2.highlab.com/buildbot/#builders/14/builds/631) of `10-rip.debian-10-buster-rtpreempt-amd64` 8completed with warnings.
10:50 PM linuxcnc-build2: Build [#631](http://buildbot2.highlab.com/buildbot/#builders/7/builds/631) of `10-rip.debian-11-bullseye-rtpreempt-amd64` 8completed with warnings.