Weiler DZ26 Millturn Conversion

 To use mesaflash to discover sserial devices, you would:

sudo mesaflash --device 5i25 --sserial

if you don't know the possible mesaflash commands,

mesaflash --help

From the hostmot2 manual page:


           sserial_port_N (N = 0 .. 3) [optional, default: 00000000 for all
           ports]
               Up to 32 Smart Serial devices can be connected to a Mesa
               Anything I/O board, depending on the firmware used and the
               number of physical connections on the board. These are arranged
               in 1-4 ports (N) of 1 to 8 channels. Some Smart Serial (SSLBP)
               cards offer more than one load-time configuration, for example
               all inputs, or all outputs, or offering additional analogue
               input on some digital pins. To set the modes for port 0 use for
               example sserial_port_0=0120xxxx. A "0" in the string sets the
               corresponding channel to mode 0, a "1" to mode 1, and so on up
               to mode 9. An "x" in any position disables that channel and
               makes the corresponding FPGA pins available as GPIO. The string
               can be up to 8 characters long, and if it defines more modes
               than there are channels on the port then the extras are
               ignored. Channel numbering is left to right so the example
               above would set sserial device 0.0 to mode 0, 0.1 to mode 1,
               0.2 to mode 2, 0.3 to mode 0 and disables channels 0.4 onwards.




 
 

Thank you for your pointers in the right direction. Helps a lot.

Unfortunately the 7i84 still does not report back. I just discovered that jumper w4 needs to be removed, even though it's not mentioned anywhere. I've been running a simple half file and use your suggested mesaflash prompt to check available serial devices. Is there something else I can do?

loadrt hostmot2
loadrt hm2_pci config=sserial_port_0=000xxxxx

loadrt threads name1=servo-thread period=1000000

addf hm2_5i25.0.read servo-thread
addf hm2_5i25.0.write servo-thread
addf hm2_5i25.0.pet_watchdog servo-thread

start

W4 is not used on the 7I84U, its position does not matter.
(note that the 7I84U was tested with the as shipped jumper settings)

What LEDs are illuminated on the 7I84U when the system is powered
(but linuxCNC not running?)

You should have 2 yellow LEDs and 1 red LED illuminated. If not, 
there is a power issue.

Do you have both FIELDA and FIELDB voltages applied? 

 

thanks, i still don´t exactly know where the problem was, but i reflashed the 5i25_7i77x2 bitfile again and it just works..

I have already asked in another estop related chat but maybe that was too old of a thread.
I have been trying to incorporate the rather complicated estop relais functionality from the original machine setup and have messed up my estop logic along the way and can not recover from all changes i have made in the meantime.
Even the easy setup i am running right now is unable to recover GUI estop from True status. I have checked behaviour in halscope and everything seems to work correctly, except somethings holding on to halui.estop.is-activated. I can find nothing about what kernel nets exist, linking internal pins to ...is-activated. What problem could be the source of that behaviour?
Thank you all


net not_aus_fault     => halui.estop.activate

setp oneshot.0.width 0.1
setp edge.0.in-edge FALSE          
setp timedelay.0.on-delay 0.05     
setp timedelay.0.off-delay 0
net not_aus_ok         => iocontrol.0.emc-enable-in
net not_aus_ok         => edge.0.in
net estop-ok-rising    <= edge.0.out => oneshot.0.in
net estop-reset-raw    <= oneshot.0.out => timedelay.0.in
net estop-reset-pulse  <= timedelay.0.out => halui.estop.reset

 

The logic for setting that HAL pin is here, it just reports the system state:
github.com/LinuxCNC/linuxcnc/blob/master..._intf/halui.cc#L2167

Is halui.estop.activate being driven at all? Is it false?

Thanks for the github link. I will look into it in detail.

Currently everything is doing what it´s supposed to do, signal wise.
When i disable the estop relais (hardware wise) i can see a reset pulse as described in the hal excerpt above, using halscope.
halui.estop.is-activated just stays in estop.
If i set F1 in gmoccapy, the GUI puts out a warning about external estops being set. I have literally no idea what net could be the reason for that behaviour.

Finding all necessary inputs for systemstate estop in those linux systemfiles on github is above my paygrade. What could trigger estop internally?
iocontrol.user-enable-out has to be TRUE aswell for estop reset to work? 

iocontrol.0.emc-enable-in probably needs to be true to release the e-stop condition. Is that happening?