Hi All,

Any idea what API call to use to enable the axes in the same way that clicking the "ENABLE" button on screen does? I would like to enable motion, set the enable output, and change the color of the on-screen enable button at the same time. Again, essentially mimicking what clicking the Enable button does.

I have tried mc.mcAxisEnable(inst, axisID, TRUE) but did not get any response from the motors (but no errors either?)

Thanks!

That is the call to enable an AXIS.  An axis is different than a motor.  An axis can drive one or many motors. 

Currently, there is no way to enable/disable a motor from script. 

Steve

Smurph,

Thanks for the reply. I’m thinking you probably gave the entire answer to my question above, but I would like to clarify what I am trying to do just in case there is a way to accomplish it.

I want to achieve the same result as clicking the enable button, but call it from a script. I’m assuming the Enable button on screen enables all the axes, turns on the axis enable outputs, sets the state of Mach to allow code to be run, and updates the graphics on screen. I want to do that (and nothing more) from within the screen load script.

I do not need to enable axes individually.

Where is the code which is called by the enable button stored? Even if this isn’t explicitly in the API, is there a way for a function in the screen load script to access the command?

Can the exact behavior of the enable button be modified (say to prevent enabling the machine if certain inputs are not present)?

There is no such thing as axis enable outputs.  There are motor enable outputs.  The concept is that motors are attached to some sort of drive that needs to be enabled.  No axis is connected to any such creature.  Enabling an axis is basically telling the G code interpreter that the enabled axis is ok to use in G code.  if the axis is not enabled and it is used in G code, the interpreter will balk.

The enable button is enabling the control and the motors.  So if that is what you want to duplicate, that API call is:

mc.mcCntlEnable(inst, 1) -- enable
mc.mcCntlEnable(inst, 0) -- enable

There is no code in the enable button itself.  It is simply a toggle button with the up and down positions tied to the stock action of "Enable On" and "Enable Off"  Open your screen in the editor and click on the enable button.  Then in the properties window, click on the little lightening bolt button to switch from the properties view to the events view.  Here you will see how the enable button is setup. 

But basically, the stock action of "Enable On" is equivalent to mc.mcCntlEnable(inst, 1) and "Enable Off" is equivalent to mc.mcCntlEnable(inst, 0).

To keep someone from pressing the enable button unless some inputs are activated, all you need to do is "disable" the enable button.    You do that with the Enabled property and scr.SetProperty() screen API function. 

scr.SetProperty(cntlName, propertyName, value)

where:
cntlName is the value of the "Name" propert of the enable button.  In my scree, the enable button is "tbutton2".
propertName is the name of the property that you wish to modify.  "Enabled" in this case.
value is what you want to set the property to.  It is always a string value.  Use "0" for disable and "1" for enable.

scr.SetProperty("tbutton2", "Enabled", "0")  -- to disable the button so that a user cannot press it. 
scr.SetProperty("tbutton2", "Enabled", "1")  -- to enable the button so that a user can press it. 

So now you need to tie that all together in the screen load, possible the signal library, or the PLC script.  The button should be disabled initially in the screen load script.  Next, the idea is to see if all of the conditions are there for the button to be enabled, or not, and set the Enabled property appropriately in the PLC or signal lib. 

Steve

Ding ding ding!!!

That’s the ticket . The control enable is exactly what I needed.

 So I was using improper semantics when describing the different elements of Mach. Let’s see if I can get it right now. The control is the overarching code which user the interpreter to read Gcode and  provide commands to the axes. The axes are logical elements which have position, velocity, and other data but are not the motor outputs... yet. The motors are the links to the physical I/O (step, direction, and enable). Motors are linked to axes and there may be more than one motor per axis, but only one axis per motor.

Thank you for taking the time to respond. It was very informative.

Mike

Used that API call and it worked perfectly! Thanks!

Have a related question. As mentioned above, I have a number of conditions (Over-Temp Alarm, Failed power supplies, etc. ) which prevent me from enabling the machine. I could disable the "Enable" button using the scr.SetProperty() call, however I feel like that isn't the best way to do it from a user perspective since it doesn't directly tell you WHY you can't enable. Furthermore, the built-in feature to prevent enabling is only exposed to the ESTOP button and the user cannot add additional items to that list.

What I would like to do is have it to when you click on the button, it either enables the machine or doesn't, but then writes the error condition in the message bar. I wrote a script which does this, but I cannot keep the toggle button from changing states to where it is Red and shows "Disable".

My plan what to change it from a toggle button to a plain button but I could not figure out how to dynamically change the appearance of a plain button (to get it to look like a toggle button), and how to find out if the control is enabled or not.

Is there a way to use scr.SetProperty() to change the text, background color, blink enable, and blink rate of a button? Is there an API call that is something like mc.mcCntlIsEnabled() to find out if the control is currently enabled or not? I couldn't figure out how to do that.

Just set the "Button State" property of the toggle button to "0" for up, "1" for down.  No need to make it even more complicated with color and text changes.  Just set the state of the existing button. 

Have a look at ALL of the properties of the various screen elements.  And do some empirical testing to see what they do.  Most can be set with scr.SetProperty().  The ones with True/False, On/Off, Up/Down are usually set with "0" or "1" and not the actual text value that shows in the properties window.  The color properties are in HTML format, e.g. "#RRGGBB" where RR is the red component, GG is the Green component, and BB is the blue component.  To truly determine what sets the property, use scr.GetProperty() to see what it brings back.  Because I'm not going to document this stuff when only .001% of our users will ever need this information.

Look at the OSIG_MACHINE_ENABLED signal state to determine the enabled state of the machine. 

Steve

Smurph,

I really appreciate you taking the time to respond here. It is helping me understand a lot more about the screen properties.

I tried doing that but used the scr.ButtonUp() property which didn't do what I was hoping. I'll try this out and see if I can get it to work.

When you say have a look at the properties, are you talking about dropping a button (or another element) on the screen and looking at what options are in the element's menu? I haven't seen a list elsewhere of what properties there are. Also, as far as SCR commands go, I have only seen a .txt document someone posted on this forum some time ago that listed what commands are available. Is there any published reference for those?

I totally get the documentation issue. I think many would much rather see features developed than documentation (so long as we can come here to get answers). Thanks for all the effort you put into answering questions like these.

No, I was talking about opening the screen editor, clicking on a particular control you are interested in and looking at the properties in the properties window.  Those are the properties that you can set with scr.Get/SetProperty().  The property names can be taken verbatim and they are case sensitive and all spaces need to be there too.  For instance, the "Button State" property of a toggle button.  The capital B and S as well as the space in the name is important. 

By clicking on each type of control, and looking at the properties window each time, you can build a list of properties for each control that you may be interested in.  Pretty much the only ones you really don't want to mess with are the "Enable With Machine" and "Enabled States" as you can paint yourself into a corner with those.  They are not considered run time changeable.  And changing control actions, signals, and scripts at run time will probably not yield the desired results either. 

scr.ButtonUp() isn't a property.  It is a function that mimics what happens when a button is let up.  It really should NEVER ever be used.  Ever.  It is there simply because there was a similar function in Mach 3.  But it doesn't follow the paradigm of Mach 4 screen programming at all. 

Steve

Steve,

Gotcha, that makes sense. I have done a lot of scripting in Mach since I got started with it, but I still have a lot to learn. I would say now, after 6 months or so, I think I am more comfortable in Mach 4 LUA than I am in Mach 3 VBA (which I used a TON). I really appreciate how much more stable, fast, and powerful it is (even if the learning curve was... painful).

I got the "Button State" to work perfectly. Took me a little while, but I needed to enter the number zero in quotes (just like you posted) in order to get it not to generate errors. I think the enable button acts exactly how I wanted it to now - thanks!

There looks to be a TON of flexibility in the screen editor that I never realized was there, that's awesome!