Configured offset in INI file not applied properly

Thanks for a quick reply tommylight, now I feel silly

I was looking for the button in the location where it appears in my real configuration generated following the Probe Basic setup guide.

 

Pressing the button you pointed out makes the simulator work as intended

I'm making some progress on tracking down offset related error on startup.

Removing the following lines from my custom.hal file:

loadrt estop_latch
loadrt oneshot count=2

addf estop-latch.0     servo-thread
addf oneshot.0         servo-thread
addf oneshot.1         servo-thread

setp oneshot.0.width 1
setp oneshot.1.width 1

#Automatically reset e-stop in UI and any fault codes on the drives
net reset-trig oneshot.0.in                      <= hm2_7i96s.0.7i84.0.0.input-00
net reset-ui   oneshot.0.out                     => halui.estop.reset hm2_7i96s.0.7i84.0.0.output-11 hm2_7i96s.0.7i84.0.0.output-12 hm2_7i96s.0.7i84.0.0.output-13

#Latching e-stop function
net estop-loopout iocontrol.0.emc-enable-in      <= estop-latch.0.ok-out
net estop-loopin iocontrol.0.user-enable-out     => estop-latch.0.ok-in
net estop-reset iocontrol.0.user-request-enable  => estop-latch.0.reset
net remote-estop estop-latch.0.fault-in          <= hm2_7i96s.0.7i84.0.0.input-00-not

#When software e-stop is detected momentarily break e-stop circuit to trigger safety relay requiring external reset
net estop-relay-in oneshot.1.in                        <= estop-latch.0.fault-out
net estop-relay-out oneshot.1.out-not                   => hm2_7i96s.0.7i84.0.0.output-00 

And restoring the following lines in my main configuration makes the error go away.

net estop-out     <=  iocontrol.0.user-enable-out
net estop-out     =>  iocontrol.0.emc-enable-in

The big question now is how the e-stop code can break the initial initialization of the work coordinate offset.

I'll keep tracing this further down the chain, if anyone has any hints or ideas they are very welcome.

Some more progress...

Removing the reference to halui.estop.reset in the my custom.hal file makes the problem go away but it also prevents the e-stop in the UI from being reset automatically when e-stop relay is reset.

loadrt estop_latch
loadrt oneshot count=2

addf estop-latch.0     servo-thread
addf oneshot.0         servo-thread
addf oneshot.1         servo-thread

setp oneshot.0.width 1
setp oneshot.1.width 1

#Automatically reset e-stop in UI and any fault codes on the drives
net reset-trig oneshot.0.in                      <= hm2_7i96s.0.7i84.0.0.input-00
net reset-ui   oneshot.0.out                     => halui.estop.reset hm2_7i96s.0.7i84.0.0.output-11 hm2_7i96s.0.7i84.0.0.output-12 hm2_7i96s.0.7i84.0.0.output-13

#Latching e-stop function
net estop-loopout iocontrol.0.emc-enable-in      <= estop-latch.0.ok-out
net estop-loopin iocontrol.0.user-enable-out     => estop-latch.0.ok-in
net estop-reset iocontrol.0.user-request-enable  => estop-latch.0.reset
net remote-estop estop-latch.0.fault-in          <= hm2_7i96s.0.7i84.0.0.input-00-not

#When software e-stop is detected momentarily break e-stop circuit to trigger safety relay requiring external reset
net estop-relay-in oneshot.1.in                        <= estop-latch.0.fault-out
net estop-relay-out oneshot.1.out-not                   => hm2_7i96s.0.7i84.0.0.output-00

I guess that Probe Basic must also have signal to halui.estop.reset somewhere which breaks silently due to me also using it in my custom.hal file.

I'll see if I can find the reference but in worst case I'll have to reset the e-stop first using the physical button/relay and then by clicking on the button in the GUI. However I'd really prefer to only have to use the physical button like it works for me in Axis.

Big success as Borat would have said, I've managed to find a workaround for this issue. However I never managed to find the underlying cause which bothers me a bit.

I started by running the following command hoping to find a HAL or Python file that referenced dsfsfsdf but it gave no useful hits

grep -rs --color 'halui.estop.reset' /bin /etc/ /home/ /lib /lib32 /lib64 /libx32 /media /mnt /opt /sbin /srv /usr /var

So instead I reverted to trial and error. I suspected that the initialization order could have something to do with it which proved correct.

In my INI file I commented out the line for the custom.hal file.

[HAL]
HALUI = halui
HALFILE = MH50V.hal
#HALFILE = custom.hal
POSTGUI_HALFILE = probe_basic_postgui.hal

And then in the probe_basic_postgui.hal I added the following line at the end of the file.

source custom.hal

After that everything works as it should and the errors on startup are gone.

im not sure what you have going on there, but it looks like some work to untangle. think that is just going to require some testing and poking holes until you get the result you are going for.

Lcvette wrote:

im not sure what you have going on there, but it looks like some work to untangle. think that is just going to require some testing and poking holes until you get the result you are going for.
 

I don't know if you saw my last post, but I managed to get it all working by changing the initialization order so that my custom.hal file is loaded after the probe_basic_postgui.hal file.

It's a workaround but it works, just don't ask me why

awesome!!!  maybe just need to add that into the postguihal file?

I just added "source custom.hal" to the end of the probe_basic_postgui.hal file for now which worked.

Sweet, glad you got it sorted!