Mesa modbus and pktUart

More
29 Jul 2023 02:16 #276504 by persei8
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-thread
In the HAL file, I have nets like:
net speed-cmd       mesa-vfd.0.speed-cmd      => mesa_modbus.00.speed-cmd
Is it a problem to have different modules with the same pin names?
 

Please Log in or Create an account to join the conversation.

More
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 realtime

Please Log in or Create an account to join the conversation.

More
29 Jul 2023 15:34 - 29 Jul 2023 15:35 #276526 by itsme
Replied by itsme on topic Mesa modbus and pktUart

...
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.
​​​​

It seems I missed Andy's new component, can you please help me finding it? Thanks!
Last edit: 29 Jul 2023 15:35 by itsme.

Please Log in or Create an account to join the conversation.

More
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
 
The following user(s) said Thank You: rodw, itsme

Please Log in or Create an account to join the conversation.

More
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
 

Please Log in or Create an account to join the conversation.

More
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.
 
Last edit: 08 Aug 2023 23:24 by PCW.

Please Log in or Create an account to join the conversation.

More
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?

Please Log in or Create an account to join the conversation.

More
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
Last edit: 09 Aug 2023 01:23 by PCW.

Please Log in or Create an account to join the conversation.

More
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.

Please Log in or Create an account to join the conversation.

More
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
Attachments:

Please Log in or Create an account to join the conversation.

Time to create page: 0.187 seconds
Powered by Kunena Forum