Tweaked Probe Basic UI fails to launch

Let me make sure we're exactly on the same page...

You want external estop button to turn on/off the UI estop button, right?
I would like my external estop to turn on and off the UI estop button.

And the problem is that you can assert an estop with the external button, but can't de-assert with the external button
...but when I reset the external one, I must manually reset the button on the UI

Basically, you want the UI estop button to be an indicator light, not a control, right?

I think the next step is for you to set up a halshow watch page and see exactly what signals/pins are doing things under different conditions.

• Machine on, UI estop de-asserted (UI button red), physical estop de-asserted (unlatched, button out)
• When you press the physical estop button, what do the following pins do
  •  iocontrol.0.emc-enable-in do? (should go low or FALSE)
  • iocontrol.0.user-request-enable
  • halui.estop.activate
  • halui.estop.is-activated
  • halui.estop.reset
• When you subsequently unlatch the physical estop button, what do the above pins do, if anything?
• Finally, when the physical button is unlatched, and you have to press the UI estop button to clear it, what do the pins do?

It sounds like you're really close, but I'm wondering if there's something interrupting the external control's ability to de-assert***.  Or the external button can assert the estop, but you need something more (in hal) than unlatching the button to trigger the reset.

*** - Well, yea - duh.  Of course there's something interrupting, but what?  Sorry for being Captain Obvious.

Brain is fizzing... I bet connecting the physical estop button signal to halui.estop.reset through a one-shot would do it.

So every time you unlatch the physical button, not only are you de-asserting the estop condition through iocontrol, you're also sending the reset signal.

net estop-external <= mesa.whatever.666.gibberish.in-00
net estop-external =>  iocontrol.0.emc-enable-in
net estop-external =>  oneshot.N.in
net estop-external-reset <= oneshot.N.out
net estop-external-reset => halui.estop.reset

Fingers crossed...

Thanks for all the efforts, but I am going to give it a rest.

Thanks for all the examples, including your suggestions and everything else I have tried, all I can do is either makes the estop stay lit, or make it flicker off then back on by using my external estop pin 15 and using it as -not

# estop
loadrt estop_latch
addf estop-latch.0 servo-thread
net estop-loopout iocontrol.0.emc-enable-in <= ***pin 15-not***
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 <= ***pin 15***

If I could simply make the pin 15-not state toggle the estop ui button back on, That would fix it, for that it is the state of the external estop. It should really be that simple, but alas, I lack the secret formula...

Now onto more obnoxious issues, like having the carousel auto reference itself on machine enable. If anyone has a suggestion where to start, let me know. And thanks once again for helping sort this out.

msrdiesel wrote:

Thanks for all the efforts, but I am going to give it a rest.


Now onto more obnoxious issues, like having the carousel auto reference itself on machine enable. If anyone has a suggestion where to start, let me know. And thanks once again for helping sort this out.
 

Something wrong with having it reference on the first tool change (or first manual pocket jog)?

If that's ok, it's not too hard to have a conditional check in the carousel jog and M6 routines.  In my case parameter #5171 is 1 if homed, 0 if not homed. 

M13 is 'reference carousel' and has this near the end:
#5171 = 1                               ; Set carousel to homed

And my 'rotate to correct pocket' routine (M10) has this in it:

;***Home Carousel***
O100 if [#5171 LT 1]                    ; Check if homed
    M13                                 ; Home if not homed
O100 endif


If you want it to be automatic on machine enable, I'm not sure how to go about that one.  Don't know how to force an M-code at startup, but someone else might offer some aid.

When you're ready to revisit the estop problem give a shout.  I've not used the 'estop-latch' comp, but that might be one of the issues.  I think you can accomplish what you want without it.

-R

 

Something wrong with having it reference on the first tool change (or first manual pocket jog)?

No, still trying to wrap my head around functionality, all the graphic needs to do is keep up with the var file "I suppose", not sure why the complexity. My issue is forgetting to reference it, then when I do the positions are all wrong, and can only recover the correct "graphic" position by restarting the ui and referencing after I un-estop it and hit the power button. We have it auto-homing, it remembers the last position, unless we encounter a power failure, so executing an M13 then would be out.

Certainly disabling the reference carousel button after first referencing it might be a solution?

Not a big deal on the referencing, just wouldn't do it that way myself. Not that I can do any better, since I barely understand THIS code, oh how I long for C# and C++, in those I can get by. 

I will look at your solution and see if it takes care of it. Thanks!

spumco wrote:

M13 is 'reference carousel' and has this near the end:
#5171 = 1                               ; Set carousel to homed

And my 'rotate to correct pocket' routine (M10) has this in it:

;***Home Carousel***
O100 if [#5171 LT 1]                    ; Check if homed
    M13                                 ; Home if not homed
O100 endif


If you want it to be automatic on machine enable, I'm not sure how to go about that one.  Don't know how to force an M-code at startup, but someone else might offer some aid.

When you're ready to revisit the estop problem give a shout.  I've not used the 'estop-latch' comp, but that might be one of the issues.  I think you can accomplish what you want without it.

-R

 

My code for M10 and M13 contain the same.

The complexity is because LCNC has a blind spot when it comes to tool changers.

LCNC recoognizes two types - random and non-random.  For random, the pocket number in the tool table is used.  For non-random, the pocket number in the tool table is ignored.

From the docs:
RANDOM_TOOLCHANGER = 1 - This is for machines that cannot place the tool back into the pocket it came from. For example, machines that exchange the tool in the active pocket with the tool in the spindle.

A non-random tool changer is like a lathe. Tool 1 is always in pocket 1 (unless you've got a Capto turret and have repeatable offsets)

Here's the blind spot...  a carousel ATC can be - usually is - a semi-random tool changer.  Your original Fadal control has 20(?) pockets, and you have 20 positions in your tool table.  But LCNC can have a million tool numbers with stored offsets, comments, ect.  You want to have a tool table with tools #1-#500.

But LCNC doesn't let you install tool #1 in pocket #5, because you've defined your ATC as a non-random.  Pocket numbers are ignored.

This is why the Probe Basic sim has the pocket number column hidden (in the custom config yaml file) - there's no point to using the LCNC tool table pocket field.

So every carousel ATC example you can find is basically a workaround to this blind spot.  Doesn't matter if the ATC is managed through Classic Ladder, python, or G-code (i.e. Probe Basic).  All of the control schemes have to come up with a way to associate a tool number with a pocket number - and keep it stored.

Thus the complicated gymnastics you find inside the Probe Basic tool macros.  The devs had to find/create persistent parameters that keep track of tools, pockets, homing status, etc.  And there are a bunch of macros because they all do different stuff - move the right number of pockets, do shortest path math, move the arm in/out for manual debugging, etc.

This is, of course, just my inexpert opinion... but I've been trying to work out my own PB ATC for some months now (off and on) and I think I understand what's going on - and why.

You've already figured out that the on-screen ATC widget is controlled through the [DEBUG...] statements in the macros.  The widget isn't just a 'nice-to-have' eye candy... it's also the only way to determine which tool is in which pocket without resorting to interrogating the parameter file.

I have a painfully long (and unfinished) thread about my ATC issues in this forum.  If you can stand reading it, you might see when/where some of the light(s) dawned on me what the heck was going on behind the scenes.

I still can't figure out how to modify the GUI without breaking linux, LCNC and Probe Basic, but I think i 'get' the ATC part now.

We had to rewrite most all of the logic for the tool changer and now it does keep up with what tool is in which pocket, and it references correctly the first time, unless you forget to reference it, then the graphical representation does not match. But restarting the ui resynchs it.

Also we do not home the carousel by moving it by one tool, it is always in the right position anytime it is advanced forward or reversed by tool counts. This might be an inherent Fadal thing, I have seen others have alignment issues, not the case for my machine though.

I have a 16 tool carousel.