CNC12 Software cycle start disabled

[kman1967]

Report attached.

We have added an operator station on our machine with Cycle Start, Tool Check and Cycle Stop buttons. I added the inputs for in the Wizard. This now disables the software buttons in CNC12 which I don't want to do. I would like operation from either.

Is this possible?

[cnckeith]

they are designed to work in conjunction.

[ShawnM]

Yes, they both can work together. If I remember correctly I had to invert the inputs I used for the second set of buttons on one of my machines.

[Sword]

Yes, if your buttons are normally open momentary buttons, you have to set them to NC in the wizard, or else the VCP buttons will be inoperable. Never understood this, but that's the way it is. We have NC, NO, and State When Triggered.

[cnckeith]

depends on your definition of "normal" i guess.

[cncsnw]

Depending on context, "normal" is either the condition of the contacts when you take the device out of its packaging and set it on your desk; or it is the condition of the contacts when the device is installed in the machine, and the machine is idle and ready to run.

The first scenario is the one you need to look at when buying devices, reading their instructions, and connecting wires to terminals. For example, the normally-open terminals of an air pressure switch will be open when no pressure is applied, and closed when pressure is applied.

The second scenario -- machine idle and ready to run -- is the one you need to look at when describing devices in your PLC logic or (one would hope) in the Acorn Wizard. For example, your air pressure switch, wired using its normally-open terminals, will "normally" be closed if the machine is ready to run. Such an input would be named something like "AirPressureOk" in a PLC program.

Unfortunately, in the Acorn Wizard the red and green "NO" and "NC" designations do not consistently mean either of these things. Instead, in the Wzard, "NO" means "requires inversion to meet the expectations of the underlying PLC logic".

Consider an external Cycle Start button. A sensible person would use a normally-open pushbutton for that purpose. Likewise, the authors of the PLC programs sensibly wrote the logic to expect a normally-open pushbutton: the input should be closed only when the operator is pressing the button. Since a normally-open button meets that expectation, it does not require inversion. Unfortunately, in the Wizard, that means you have to describe it as "NC" even though it is not.

That is unnecessarily confusing, and Centroid should fix it. Fixing it means providing the Wizard with a list of the expected state for each of the canned input definitions, so that the user can specify the actual button state (using the second scenario above, "what is its state when the machine is ready and idle"); and then the Wizard can apply inversion whenever the user's selection is opposite the default selection.

In the mean time, users are left in the position of guessing, using trial and error, or reading the PLC program source to find out whether a given input is expected to be normally-open or normally-closed.

[Gary Campbell]

Well said Marc. There is a deep rooted long standing "programmer bias" in the PLC code intentionally set for reasons I cannot wrap my head around.

Normally open and closed devices are binary, in other words, as simply as any actionable device can be. 2 choices, represented as zero or one. There is no reason whatsoever for an inversion, we simply expect or perform an action when the signal is zero or one.

Most devices, like the air pressure switch Marc mentioned above, usually have both NO and NC contacts to allow compliance with the programmers sometimes convoluted logic... Thankfully.

Maybe someday.....

[cncsnw]

There are good uses for inversion, especially in the home/hobby market where customers insist they should be able to use what they have (e.g. normally-open prox sensors in place of limit switches) instead of having to buy something more appropriate.

The PLC program's "native" behavior, though, should follow basic fail-safe guidelines: If it is a start/go/permit input, then it should be normally open and require closure to make activity happen. If it is a stop input, then it should be normally closed, with an open input stopping activity.

I am guessing that when the Wizard interface was originally designed, thought was only given to the short list of essential inputs: EStopOk, LimitOk, DriveOk, SpindleInverterOk, LubeOk, etc.. Since all of those are "stop" actions, it was assumed that any use of a normally-open device would require inversion.

[kman1967]

Thanks all for the replies. Working now. Yes, I had to invert the conditions in the Wizard. This is confusing and I would have not thought to do that as it goes against the logic in my head. Not sure the underlying concept on why Centroid has done it like this but hey, I'll go with it. I am glad Centroid has a good user forum like this though.

[cnckeith]

having a button that closes the input is the easiest to under stand in this case.

for cyclestart2,feedhold2 buttons in the wizard i have my button input set green which = do the logic assigned to the input when input is made. my button closes the input when depressed. when button is depressed the LED goes green in the alt i screen. green = do the logic assigned to that input.

the confusion starts when a button OPENs the input which you set to be RED in the Wizard input menu. RED = input not made, input is open. when button is depressed input is open. then what happens in the alt i screen is an input inversion so led is red with a line above it when the input is made. so red with line above it = do the logic assigned to that input.