Mesa modbus and pktUart
29 Jul 2023 02:16 #276504
by persei8
In the HAL file, I have nets like:Is it a problem to have different modules with the same pin names?
Replied by persei8 on topic Mesa modbus and pktUart
loadrt mesa_vfd
addf mesa-vfd.0 servo-thread
loadrt mesa_modbus ports=hm2_7i96.0.pktuart.0
addf mesa_modbus.00 servo-threadnet speed-cmd mesa-vfd.0.speed-cmd => mesa_modbus.00.speed-cmdPlease Log in or Create an account to join the conversation.
29 Jul 2023 02:42 #276507
by persei8
Replied by persei8 on topic Mesa modbus and pktUart
Just did more checking:
jim@Inspiron-1720:~/linuxcnc/configs/modbus$ halrun
halcmd: loadrt mesa_vfd
Note: Using POSIX realtime
halcmd: show pin
Component Pins:
Owner Type Dir Value Name
4 u32 OUT 0x00000000 mesa-vfd.0.motor-cmd
4 u32 OUT 0x00000000 mesa-vfd.0.speed-cmd
4 float OUT 0 mesa-vfd.0.speed-fb
4 float IN 0 mesa-vfd.0.speed-in
4 float IN 0 mesa-vfd.0.speed-rpm
4 bit IN FALSE mesa-vfd.0.spindle-on
4 s32 OUT 0 mesa-vfd.0.time
halcmd: show param
Parameters:
Owner Type Dir Value Name
4 u32 RW 0x00000000 mesa-vfd.0.max-speed
4 u32 RW 0x00000000 mesa-vfd.0.min-speed
4 s32 RW 0 mesa-vfd.0.tmax
4 bit RO FALSE mesa-vfd.0.tmax-increased
halcmd: show funct
Exported Functions:
Owner CodeAddr Arg FP Users Name
00004 7f6973eac1b5 7f6973043120 YES 0 mesa-vfd.0
halcmd: loadrt threads name1=test-thread period1=1000000
halcmd: show thread
Realtime Threads:
Period FP Name ( Time, Max-Time )
1000000 YES test-thread ( 0, 0 )
halcmd: addf mesa-vfd.0 test-thread
halcmd: show thread
Realtime Threads:
Period FP Name ( Time, Max-Time )
1000000 YES test-thread ( 0, 0 )
1 mesa-vfd.0
halcmd: start
halcmd: rtapi_app: caught signal 8 - dumping core
Waited 3 seconds for master. giving up.
Note: Using POSIX realtimePlease Log in or Create an account to join the conversation.
29 Jul 2023 15:34 - 29 Jul 2023 15:35 #276526
by itsme
Replied by itsme on topic Mesa modbus and pktUart
It seems I missed Andy's new component, can you please help me finding it? Thanks!...
A better approach might be to attract Andy's attention and work with his shiny new component. I'm sure he'll help as that was his intended use.
Last edit: 29 Jul 2023 15:35 by itsme.
Please Log in or Create an account to join the conversation.
29 Jul 2023 17:03 #276530
by persei8
Replied by persei8 on topic Mesa modbus and pktUart
Well I found a workaround, don't know if it's the right fix or not, but if you setp the component parameter pins first and then addf, the problem doesn't occur.
Andy's shiny new component -> New realtime-modbus driver for Mesa cards - LinuxCNC
Andy's shiny new component -> New realtime-modbus driver for Mesa cards - LinuxCNC
Please Log in or Create an account to join the conversation.
08 Aug 2023 16:35 #277334
by persei8
Replied by persei8 on topic Mesa modbus and pktUart
I find that occasionally the FAULT pin is asserted for no discernible reason (other than FAULTCODE) and there is no way to clear it other than exiting and restarting linuxcnc. Is the faultcode an index to the list of messages defined in mesa_modbus.c? (I'm guessing it is, but would like it confirmed). Would it be possible to provide a means to reset the mesa_modbus component? (ie. a RESET input pin)
Jim
Jim
Please Log in or Create an account to join the conversation.
08 Aug 2023 20:33 - 08 Aug 2023 23:24 #277371
by PCW
Replied by PCW on topic Mesa modbus and pktUart
I think the last-error pin just reflects the last error,
It should not affect communications. The fault pin gives
the current communication status. A fault count pin
might be a nice addition.
With my test setup I start with an error code of 0 but
if I interrupt communications, the fault pin is asserted
the last error pin changes to 11 ("com timeout")
if i re-establish communications, the last error remains
11 but the fault clears, and communications are re-established
Do you have bias resistors on the 7I96S serial port?
These are needed for RS-485 communications to set
the undriven line state to idle:
1 GND
2 RX+,TX+ 330 Ohm pulldown to GND (1)
3 RX-,TX-
4 RX+,TX+
5 RX-,TX1- 330 Ohm pullup to 5V (6)
6 +5V
Also you should use the 7i96s_pktv2 firmware
as it has an improved PktUART with better error resistance
and more accurate low baud rates.
EDIT: I have found by torture testing (power cycling the modbus remote while running)
I can generate a unrecoverable (stack smash) error. I believe this is because when power cycling
many bogus RX characters can be generated and the number of RX characters exceeds the max
character limit in the .mod file
I have been able to work around this by setting the max character limit to the maximum (251)
but it should probably be fixed in the driver by truncating at the limit or some other validation method.
It should not affect communications. The fault pin gives
the current communication status. A fault count pin
might be a nice addition.
With my test setup I start with an error code of 0 but
if I interrupt communications, the fault pin is asserted
the last error pin changes to 11 ("com timeout")
if i re-establish communications, the last error remains
11 but the fault clears, and communications are re-established
Do you have bias resistors on the 7I96S serial port?
These are needed for RS-485 communications to set
the undriven line state to idle:
1 GND
2 RX+,TX+ 330 Ohm pulldown to GND (1)
3 RX-,TX-
4 RX+,TX+
5 RX-,TX1- 330 Ohm pullup to 5V (6)
6 +5V
Also you should use the 7i96s_pktv2 firmware
as it has an improved PktUART with better error resistance
and more accurate low baud rates.
EDIT: I have found by torture testing (power cycling the modbus remote while running)
I can generate a unrecoverable (stack smash) error. I believe this is because when power cycling
many bogus RX characters can be generated and the number of RX characters exceeds the max
character limit in the .mod file
I have been able to work around this by setting the max character limit to the maximum (251)
but it should probably be fixed in the driver by truncating at the limit or some other validation method.
Last edit: 08 Aug 2023 23:24 by PCW.
Please Log in or Create an account to join the conversation.
09 Aug 2023 00:27 #277383
by persei8
Replied by persei8 on topic Mesa modbus and pktUart
"if i re-establish communications, the last error remains
11 but the fault clears, and communications are re-established"
How do you re-establish communication? I find that once the FAULT pin is asserted. it no longer communicates with the VFD and I have to exit linuxcnc and restart. It would be nice to be able to programmatically restart communication, for example, by toggling a RESET pin.
I have a 7i96 non S version. Does it still need the bias resistors?
11 but the fault clears, and communications are re-established"
How do you re-establish communication? I find that once the FAULT pin is asserted. it no longer communicates with the VFD and I have to exit linuxcnc and restart. It would be nice to be able to programmatically restart communication, for example, by toggling a RESET pin.
I have a 7i96 non S version. Does it still need the bias resistors?
Please Log in or Create an account to join the conversation.
09 Aug 2023 01:09 - 09 Aug 2023 01:23 #277387
by PCW
Replied by PCW on topic Mesa modbus and pktUart
The 7I96 also needs the bias resistors
Reset does not make much sense as communications should restart automatically
and if not, the reason should be determined and fixed.
On my setup I can unplug the serial connector get the expected fault
and it always reestablishes communications and clears the fault when
re-plugged.
Do you get any errors on the console when you get the unrecoverable
fault? (start LinuxCNC in a terminal)
Is it Linuxcnc that needs a restart or power cycling the VFD?
Are you using the V2 PktUART firmware: 7i96_pktdv2.bit
Reset does not make much sense as communications should restart automatically
and if not, the reason should be determined and fixed.
On my setup I can unplug the serial connector get the expected fault
and it always reestablishes communications and clears the fault when
re-plugged.
Do you get any errors on the console when you get the unrecoverable
fault? (start LinuxCNC in a terminal)
Is it Linuxcnc that needs a restart or power cycling the VFD?
Are you using the V2 PktUART firmware: 7i96_pktdv2.bit
Last edit: 09 Aug 2023 01:23 by PCW.
Please Log in or Create an account to join the conversation.
09 Aug 2023 01:23 #277388
by persei8
Replied by persei8 on topic Mesa modbus and pktUart
Ok, I better find some resistors then.
I did flash the 7i96_pktdv2.bit file.
When the FAULT is active, there are no messages on the console, I just can't turn on the spindle. Restarting linuxcnc clears it without cycling power to the controller or the VFD. Maybe the problem is that I don't have the resistors, so I'll fix that first and go from there. Thank you for the info.
I did flash the 7i96_pktdv2.bit file.
When the FAULT is active, there are no messages on the console, I just can't turn on the spindle. Restarting linuxcnc clears it without cycling power to the controller or the VFD. Maybe the problem is that I don't have the resistors, so I'll fix that first and go from there. Thank you for the info.
Please Log in or Create an account to join the conversation.
13 Aug 2023 19:41 #277862
by persei8
Replied by persei8 on topic Mesa modbus and pktUart
Another development in this saga. First of all, I updated to bookworm and kernel 6.3.0-rt11 according to rodw's instructions. I think the error-finishing-read errors are now gone. However, there is still something fishy with the mesa_modbus component. If the FAULT signal is not asserted, I cannot perform homing because there are constant joint.0 following errors. If I unplug the cable to the VFD with the modbus signals, thus causing FAULT to assert, the following errors disappear and I can perform homing. The frequency of the following errors is very close to the mesa_modbus update rate. To prove this, I halscoped the signals with the refresh rate at 4 Hz and again at 5 Hz. What I don't understand is why the joint.0.motor-pos-cmd has spikes. It should have nothing to do with modbus or spindle control.
Jim
Jim
Please Log in or Create an account to join the conversation.
Time to create page: 0.257 seconds