Gmoccapy - A new screen for linuxcnc

Hallo,

so let me jump in, before we get a mix of things
This is not a gmoccapy isue, but a hal connection problem!

So you have connected parport pin 8 to the signal spindle-brake, correct?
That signal is also connected to motion.spindle-brake

so in your hal file there must be two lines like (please correct the pin names, I have no computer availible with linuxcnc here)
And the gladevcp button should loose the spindle brake, is that correct?
If so, we need a or component and connect the stuff as follows.
Please do that in your spindle-brake.hal file to avoid race conflicts, leave the actual lines in your main hal commented out!

Imagine the signal names being a cable , the first argument is a sender and the second is the receiver
like so:

net red_cable plug_in_the_wall => coffee_machine

you can not connect a tee cocker to the plug from the coffemachine, but to the cable so
net red_cable tee_cocker is OK
but net red_cable plug_from_the_tee_cooker is not OK!

Hope that does explain a little the problem you are having. With the or component we included a "double-plug"

man or2 gives good help

Norbert

Caleb here again. Okay, I think this is some really good help. The "or2" sounds like probably the way to go, I just needed help with the syntax, but I think I'm understanding it. One question I have: If I'm interpreting right, with this setup, the new toggle switch will still be *independent* of the spindle motion, and whether or not the brake is applied will be a function (using AND/OR/NOT operators) of both the state of the toggle button and whether or not the spindle is in motion. Is that correct? If so, my *guess* is that my dad will be fine with that, and we'll set it up so that the brake is applied *only* when the spindle is *not* in motion *and* the toggle button is pressed down, and otherwise the brake will be released.

However, my guess is that what my dad was probably most hoping for is for the new button and the automatic changes based on spindle movement to be connected, so that anytime the spindle begins moving, the brake is unconditionally released and the button becomes un-pushed to reflect this, and anytime the button stops moving, the brake is unconditionally applied and the button becomes pushed to reflect this. But, I don't know for sure that that's what he wants -- maybe he would actually prefer the situation I described above, where the button and spindle motion are independent, and for the brake only to be applied when the button is pushed and the spindle isn't moving. In fact, although I don't know for sure, the more I think about it, the more I suspect that it is what he wants. So, again, it's sounding like using the OR/AND operators are the way to go, and I think that example of syntax should be enough to help me figure out how to implement it right. Huge thanks to everyone for the continued help.

Cheers,
Caleb

Hallo Calep,

the way I connected it will loose the spindle in two ways:

If motion.spindle-brake gets hight, also pin-08 will get hight and loose the spindle
if the button is pressed, pin-08 will get also hight and the spindle brake will open.

as long as the button is pushed, the brake will be opened!

If you want a way to "reset"the button if the motion.spindle-brake changes its state, I would take a look on a flip-flop component.
It would be possible to reset the button also using a python handler.

So first we need to clear exactly what you are expectiong the button should do!

Norbert

Sometimes the simplest thing to do is write out all the posible logic states and what you want to happen, then go from there.

motion.spindle-brake		Button		Spindle brake on
1		0		0
1		1		1
0		0		0
0		1		0

For the above I believe a simple and2 should suffice.

Sometimes the simplest thing to do is write out all the posible logic states and what you want to happen, then go from there.
motion.spindle-brake Button Spindle brake on
1 0 0
1 1 1
0 0 0
0 1 0
For the above I believe a simple and2 should suffice.

Yeah, I've already done that much I don't think your particular values are quite right (but maybe you were just trying to give an example, and not necessarily trying to provide everything exactly as it should be), as it seems to me like the spindle brake should never be set if the spindle is in motion (but I will double check that with my dad). Further complication is that, from what I've observed, I believe the brake is *set* if the pin is *off*, and *released* if the pin is *on*. So it takes some careful thought to come up with the right truth table, but I think I've got that part pretty well under control. Thanks.

Cheers,
Caleb

Norbert --

I told my dad how the or2 solution is going to look and feel, and he's completely great with that, so I don't think we need to mess around with flip-flops and Python handlers. I'm thinking we're probably good for now, especially with the example of or2 usage you provided. But I'll post again if we run into more problems that we can't solve on our own. Thanks again!

Cheers,
Caleb

Whee! It's working perfectly now. As it turns out, I was wrong about the brake being released if the pin is on and set if the pin is off. It's the other way around; if the pin is turned on, the brake is set, and if the pin is off, the brake is released.

What was throwing me off was that "motion.spindle-brake" -- I discovered using the "halshow" utility that if *that* is *off* then it means the spindle *is* in motion, but if it's *on* then it means the spindle is *not* in motion. What we want is for the brake to be set if and only if the spindle is *not* in motion *and* the new button I added is pressed. So, that ended up just being a simple, straightforward AND operation between the spindle motion signal and the button. Interestingly, this also means that the values in Todd Zuercher's truth table were actually exactly right. Todd, did you somehow know that the "motion" signal would be *off* if the spindle *is* moving, and *on* if it's *not* moving? Anyhow, spindle_brake_button.hal now looks like this:

Now everything works just as he wants.

Again, huge thanks to everyone who contributed to helping us get this worked out!

Cheers,
Caleb

Actually yes I did. I checked the function of the motion.spindle-brake pin in a VM simulation before I posted.