Machsupport Forum

Mach Discussion => General Mach Discussion => Topic started by: Mike VT on August 10, 2016, 08:19:43 PM

Title: Normally Open VS Normally Closed
Post by: Mike VT on August 10, 2016, 08:19:43 PM
This is a good one.  Would like to hear the arguments that go to the heart of the reasoning.

To start, lets say axis A (maybe a tool changer moving in and out from limit 1 to limit 2).

Why should the limit switches be wired one way or the other. 

This will be fun as most opinions will be based on previous readings from the net without any actual thought to the real question.

  All my limits were wired N.O.........Good thing, because Mach 3 has a bug with "IF NOT"

Fire away.

Title: Re: Normally Open VS Normally Closed
Post by: Peter Homann on August 10, 2016, 10:39:17 PM
All commercial machines that I'm aware of use normally closed switches on limit circuits.

The reason for this is safety. With a normally open switch, your relying on the switch closing, completing the circuit and activating the input.  If a wire to the limit switch is broken (or not plugged in properly), then when the limit switch is closed, the input is NEVER activated. In some large machines this would destroy the machine.

Using a normally closed circuit, the input circuit  is closed in the normally operating condition. When the limit switch is hit and opened the input is activated. The advantage of this system is that the limit input will also be activated if a wire breaks or a connector becomes unplugged.

There is nothing to debate on this one.

Cheers,

Peter
Title: Re: Normally Open VS Normally Closed
Post by: Highspeed1964 on August 10, 2016, 11:28:29 PM
Agreed.  Peter has said it all.  Safety.

Now, as far as the Mach3 bug, are you writing a macro to check the status of the limit/homing switches?  No need to do IF NOT.  Just set the switch input to an active high when using normally closed switches (wired in series of course) and you're done.  The logic for macros is still the same, IF <limit switch state = TRUE> THEN STOP (or whatever action you need to do).  No need to do an IF NOT check.  You could also do an IF <limie switch state = FALSE> check if you need to make sure the switch is NOT active.

Hope this makes sense.

Stephen "Highspeed" Kruse
Title: Re: Normally Open VS Normally Closed
Post by: Davek0974 on August 11, 2016, 02:12:58 AM
Industry standard safety relays like PILZ, PREVENTA et al, all use N/C switches and cannot be configured to use N/O switches on the safety monitoring side.
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 11, 2016, 10:05:07 AM
As I do a lot of industrial wiring I can add a few things.
Safety circuits such as E-Stop are generally wired in series meaning the output of one switch is wired to the input of the next and so on.  So these have to be wired NC so that there is a High signal to indicate the end of a circuit.  If any one switch is pressed, this opens the entire circuit.  If any wire is broken, this opens the entire circuit.  Very clearly the way to go and was figured out a long time ago.

For limit switches, there are two configurations commonly used.  If there is a manual switch that can move something, we will generally run the output of the switch through the NC contacts on the limit switch and then on to the starter.  This has as much to do with convience as it has to do with safety, it is merely an easy way to minimize wire pulls back to a remote cabinet housing the contactor.  If we use NO on the LS, then this would require an extra wire going back and would require a relay to break the circuit.  In this setup, it is safe to run the axis as long as the limit switch is Not Tripped.

In the case of a tool carosel, it is very different.  We want to know that it is either IN or OUT.  We really don't care where it is if it is somewhere in the middle.  We just know it is not safe to do anything until it is either IN or Out.  In this setup, it is considered safe to do something, when the limit switch IS Tripped.

Lets think about this.  In the OUT position, the machine is safe to run (with regards to the carosel anyway).  If I wire this LS normally closed, this means that when the carosel is OUT, the signal from this limit switch is OFF.   Heres where I disagree with the safest way to consider this.  If the wire is broken, is it more likely to short to a high signal, be cut clean, or be shorted to ground?  All are possible with the cut clean and shorted to ground being by far the most common.  With that said, if we use NC contact, we will be fooled into thinking the carosel is out anytime we have a circuit fail.  For example, the carosel is not quite all the way out and it is not safe to run the machine.  The out LS wire has broken.  We can monitor the IN LS but this only tells us that it is somewhere besides completely IN.  Not enough information.  My broken wire on the OUT LS indicates its OUT but it is not.

Peter mentioned above
"Using a normally closed circuit, the input circuit  is closed in the normally operating condition"

This is only relavent to a STOP circuit. When talking about LS, this statement would be exactly backwards if you were using NC contacts.  Normally Closed means that the contacts are closed when the switch is NOT activated.  In our Carosel example, the safe zone is when the switch IS activated.

Peter went on to say:
"When the limit switch is hit and opened the input is activated."

But this is only because you inverted the logic on the controller (mach3).  The actual input is deactivated and software flips this logic.

"The advantage of this system is that the limit input will also be activated if a wire breaks or a connector becomes unplugged."

In my opinion, this is absolutely the un-safest way to do this.  If a wire breaks or a connector becomes unplugged, this setup tells the controller that the carosel is against the OUT LS when in fact, it could be anywhere in the middle.  This is the essence of what I am getting at.

I think there is a lot of confusion between a Safety Stop Circuit and the use of Limit Switches.  Limit Switches are not saftey stop ciruits and are rarely wired in series with other components except when using a manual switch to activate some thing.  Generally, this is not what we are doing.  We are wiring a LS to a controllers input to determine if something is safe to move or not.  Its our job to try to predict the likely failures such as broken wires, and stuck limit switches.  I argue that in the carosel example, using NO contacts is a more reliable solution as it actually does catch the broken wire problem.  I think it comes down to this.
The input should be ON (actual input and not inverted by software) when the "thing" in question is in a safe operating position.  With that being said, on these types of machines, there are two different things going on.

X,Y and Z limit swithes are used to indicate that the axis is between limits and thus should provide a High signal when not on one of the limit switches.  Therefore, we should use N.C. contacts.  If a wire breaks, it indicates that a limit is tripped and we stop the machine.
Carosel In/Out, Carosel rotate fwd/rev, gear boxes, tool change.....these limit switches are used to indicate that something is exactly where it should be and should provide a High signal at that point.  Its only safe, when we are actually on these limit switches, so they should be wire using the N.O. contacts in my opinion.

This is how I wired my machine.  Almost all the documentation I read issues blanket statements about using N.C contacts when in fact, there are three primary situations to consider and they all three are different.  Stop circuits, LS used to declare its unsafe when tripped, and LS used to declare its unsafe when Not tripped.


Title: Re: Normally Open VS Normally Closed
Post by: Davek0974 on August 11, 2016, 10:16:53 AM
I always try to wire my stuff with e-stop being N/C for reasons all have mentioned, all my input signals - buttons, homing, in your example the tool carousel position sensors I would always wire N/O so that a signal is provided to show intention - a button pressed, a proximity sensor in range of target, the tool carousel being in or out but not both or neither (needs logic here, OR gate i think).

Thats how i do stuff and it seems to make sense, rarely will a short circuit on an input be able to create a 24v signal, more likely short to chassis or just go open circuit so its a pretty safe system.

JMHO ;)
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 11, 2016, 12:03:22 PM
One of the reasons I brought all this up was the consideratiion of predicting failure.  I recently converted a Haas VF1 to Mach3.  Coming down the home stretch to finish it up.  Took my first cuts last week and all is good.

Whats missing is refining the software to be smart and look for failed components.  I.E.  broken wires, stuck limits....

All of my basic functions work great as long as nothing goes wrong.  Have to go back now and myticulously study the macros and put in all the things to catch failures.  This is what got me thinking about this topic.

We discussed the broken wire but what about a stuck limit switch.  Very common.

The software should have tons of checks in it.  In the carosel example, and using N.O. contacts for the In and Out LS, we should be looking at several things and not just firing an output and looking for an input.
Example:
Carosel is Out and I want to send it in to do a tool change.  Out LS is ON and IN LS is off.  This should be the first check in the program.  Confirm current state.  Turn on Output to send it in, wait to see the IN LS come on.  Confirm the Out LS cut off.  Add a time limit for all this to happen.  Repeat for sending it Out.
This will catch broken wires and stuck limit switches.  My current macros only fire an output and look for the input.  No other checks.  It would be really easy to leave it like this and hope for the best.  Matter of fact, I bet a bunch of folks have done this.  Anyhoo, my macros are about to double in size.  Hope some of this is helpful to others.
Title: Re: Normally Open VS Normally Closed
Post by: Highspeed1964 on August 11, 2016, 01:02:04 PM
Again, I don't see a need to make major changes to the macro.  No matter if it's NO or NC, due to the configuration of ACTIVE LOW for NO or ACTIVE HIGH for NC the logic in the macro would be the same.  If <switch active> THEN <do something> or IF <switch inactive> THEN <do something different>.  You could also use IF <switch active> THEN <do something> ELSE <do something different>; or even IF <switch inactive> THEN <do something different> ELSE <do something>.

The bottom line is the wiring does not change your macro logic as long as you have the configuration set in Ports and Pins to handle it appropriately.

Highspeed
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 11, 2016, 01:39:44 PM
I understand exactly what you are saying.  My major changes to my macro are not related to that.  I was trying to say that I got the machine working and it would be very easy to just go make some chips.  Adding lines of code to catch all the possible hick ups can be quite involved when done correctly. 

For example, with my carosel above, the first thing to do is to verify its actually in the OUT position by looking at both LS signals.  My current program does not do this because I was trying to just get it to work.  This one check at the beginning will be added lines of code with some way to end the routine and send appropriate message that it ended because of this.  Or maybe you choose not to End the routine but perhaps try to send it Out and see if the LS states can be verified and maybe you continue with the task.  Maybe not.  Then on to the next check, fire the output for x number of seconds (again, my code does not yet do this), look for IN LS, double check that Out LS changed state and check that the the timer didn't expire.  Add lines of code for each of these checks.  End routine and send error message that clearly states why it ended.  Decide if you are going to leave that carosel somewhere between the LS's or do you try to send it back out.   

So my point being that in this case, we haven't even gotten to changing the tool and there's quite a bit to think about and write code.  Then test and besure the darn macro doesn't get hung up somewhere.  Had my VB programming skills not been 25 yrs sitting on a shelf, perhaps I would have put all this stuff in the first time.  Very glad I did not as I was able to get things going in a piece by piece way.  Now to do the right thing and finish it correctly.
Title: Re: Normally Open VS Normally Closed
Post by: Davek0974 on August 11, 2016, 01:47:29 PM
I would simply send the carousel out, with a timer loop of maybe 2s - if it does not hit the out switch within that time then fault out of the macro with a message on screen.

No second chances - you never know why it did not hit the limit so not worth the risk of trying again, it won't fix itself ;)

The rest of it is simple if-then loops etc and some friendly informative screen messages.
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 11, 2016, 02:48:31 PM
Like I said, the first thing to do is verify it is OUT before you even start.  This should be verified by looking at both LS's.  Then you get to fire it IN for X seconds while checking the change of state on BOTH LS's.  Thats 3 possible faults right there.
Carosel was not OUT before attempting tool change (Drifted off the OUT LS somehow or broken wire, or bad LS)
Carosel failed to go to IN LS within x seconds (just failed to make it-could have hit something, fuse could be blown-could be locked up, broken wire, LS could be bad)
Carosel IN LS found but OUT LS was still made (Out LS is stuck or its wire is shorted High)

Again, this is just the very beginning of a tool change routine and theres a fair amount of IF's to be added if you really want to create a safe machine that will fault and tell you why it did.

Just sending it IN and only looking for the IN LS within x seconds is really not adequate IMO.  Its just enough to make it work and maybe not burn up the motor if it gets hung.  Actually catching broken wires or stuck LS's takes a little thought and some more code.  For example- Suppose the OUT LS is stuck ON.  If you don't check the state of the OUT LS before AND after the Move IN (I.E. you only looked at the IN LS), you are going to likely have a crash a few seconds from now when you send it back OUT.  Why, because the OUT LS was already ON when you sent it out, so you barely moved it away from the spindle and all looked good to the controller because the OUT LS was made within 2 seconds.  But it wasn't and here comes the spindle at G0 speed (300 ipm in my case) and a 6 inch face mill spinning away.  As the carosel is ripped from its mounts, the face mill suddenly finds it and 15 other tools that it can now try to kill you with and may very well do so because we really hated that door switch.


My point to this thread was to shine a little light on the NO and NC LS's.  The point to any argument about them is safety.  Understanding why one or the other is safer and writing programs that enhance the concept is pretty darn important.  Making something work is easy.  Making something safe requires more than blanket statements about always use NC contacts because thats how its done.
Title: Re: Normally Open VS Normally Closed
Post by: Highspeed1964 on August 11, 2016, 03:29:40 PM
Ok, I understand your point about additional programming for the functionality.  My point is that the logic of your programming shouldn't have to change as a result of changing from NO to NC if you configure Mach3 Ports and Pins to match accordingly.  Any additional programming would be for desired additional logic needed for functionality, not wiring configuration.

Stephen "Highspeed" Kruse
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 12, 2016, 05:30:43 PM

Sorry for being so direct.  I do a lot of industrial NC upgrades with up to 50 axis at a time, all PLC based.  Thought I would share but see now its not that easy or more specifically, I'm not so good at it.


My tool change code went from almost 2 pages to over 5.  I tried to catch every event possible and it has already saved several crashes.

For instance.  I am using the CSLabs hardware.  Got everything working great with some mechanical mods to compensate for lack of speed in software macro comms.

Tried to add a coolant check function, meaning if it was on before a tool change, turn it off and then back on after tool change is complete.  Simple.

Couldn't figure out (and still haven't) how to properly check the output status of the coolant using cslabs hardware.   Messing around, I ended up opening the CSLabs Plugin page which gives a visual led for each input and output.  Continued messing around with different calls from the manuals to see if it was on or not.  Immediately,  My new tool change macro started saving me.  Turns out, with that CSLABS plugin window running, the scan time went to crap causing my carosel to rotate too far on each tool change.  Result was carosel was not aligned and new macro caught it.  I'm pretty sure the comms were just pinging away at the cslabs hardware to update those little led's and the macro comms cycle time was cut in half. Good to know.

Would have been real easy to have live tools in and testing it out because everything was fine a few minutes ago.  When I converted my knee mill a few years ago, I got it going and that is it.  With this machine's power and additional functions, I kinda get it.  Better buck up and do the extra code to really make it safe.

Again, sorry for the directness.  I'll work on that.
Title: Re: Normally Open VS Normally Closed
Post by: Hood on August 12, 2016, 06:46:23 PM
Regarding the coolant, if needing it in the toolchange macro then just look at the Mach LED for the Flood coolant, for example if the following was in your M6Start.m1s

If GetOemLED(13) Then
DoOemButton(113)
End If

It would switch off the coolant if it was on.

You could also use code in the macro, for example

Code "M9"

that would switch the flood and mist off if it were on.


Hood
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 12, 2016, 08:14:08 PM
Thanks Hood,
Is there a known method to simply look at the cslabs output in question.  Reason being, I have a bunch of things planned that would require looking at any given output state.  Just getting started and seems none of the documentation is correct.  Could be my old eyes.....
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 12, 2016, 08:23:14 PM
Hood,
I have noticed considerable issues when trying to call another M function within a macro.  Are you saying this works?????
Calling M9 from M6 is Okay?
Title: Re: Normally Open VS Normally Closed
Post by: Davek0974 on August 13, 2016, 03:13:44 AM
Thanks Hood,
Is there a known method to simply look at the cslabs output in question.  Reason being, I have a bunch of things planned that would require looking at any given output state.  Just getting started and seems none of the documentation is correct.  Could be my old eyes.....


Yes there is but i cant recall it, i found a document on their website that shows exactly how to examine every out and in port state, something like GetOutput(Bit...) but don't try that it was guess.

The docs are on their site somewhere.

Or have a look in their pre-writtenmacro samples, they use the codes a lot
Title: Re: Normally Open VS Normally Closed
Post by: Hood on August 13, 2016, 05:46:23 AM
Thanks Hood,
Is there a known method to simply look at the cslabs output in question.  Reason being, I have a bunch of things planned that would require looking at any given output state.  Just getting started and seems none of the documentation is correct.  Could be my old eyes.....



Think I linked you to the I/O info page before but here it is just in case it was someone else.
http://www.cs-lab.eu/en/upload/fotki/Elementy,%20banery/CSMIO-IP-A%20artykuł.jpg

Now I am not sure about OutPuts, you can set them from VB but monitoring I am not sure, then again you could always just set it to the state required, if it was already in that state then it likely would not matter.

Hood,
I have noticed considerable issues when trying to call another M function within a macro.  Are you saying this works?????
Calling M9 from M6 is Okay?

I do it in a few macros, just thinks like M3, M8 etc but never had an issue, they are always called via the Code"....." method. As an example my toolchange macro on the Chiron will call a M3S200 as the spindle needs to be rotating whilst the tools are being changed.

Here is the Chirons macro, as you will see I command a move and turn on the spindle from the M6Start.m1s.

Hood

Code: [Select]
'Toolchange macro for Chiron FZ12S
 

 
 If GetSelectedTool()=GetCurrentTool() Then
  End
 End If
 
 Code "G53G0Y310Z-.5M3S200"
 While IsMoving()
 Wend

SetTool =GetSelectedTool()

 
 
  tool = GetSelectedTool() Mod 12
  If Tool = 0 Then
  Tool = 12
  End If
 
 
 Do                                       
 Call SetModOutput (tool,1)                 
 If GetInput (tool) Then Exit Do 
 Sleep 10
 Loop
 Call SetModOutput (tool,0)
 SetCurrentTool( SetTool )                                 
                   




Title: Re: Normally Open VS Normally Closed
Post by: stirling on August 13, 2016, 05:49:56 AM
Re: your "if not bug". see your other thread at http://www.machsupport.com/forum/index.php/topic,32497.msg228208.html#msg228208
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 12:15:16 PM
Thanks Stirling.  I responded in the other post.  You helped a lot.  Got me on the path early on.  Thanks,

So here is what I learned on the coolant.
There does not seem to be a way to monitor the outputs on the cslabs.  Not directly anyway.

So, I had this.

If OEMLED(13) Then
Coolant=1
ReSetOutBit(90,2)  'coolant pump output
Else
Coolant=0
End If

So what happened here when the coolant was on is that my code works except Mach is apparently Setting the coolant ON over and over and over.  So my Resetoutbit probably did work but Mach immediately turned it back On in its next communication with cslabs. 

So simply replacing the ResetOutbit(90,2) with Code "M9"  works perfectly well.  Or doing the OEMButton.  Exactly as Hood said.  Its interesting to me anyway, that Mach constantly sends a SetOutBit to the controller.  I would think that is the kind of thing that creates a lot of overhead in communications and speed.  Or maybe thats not what's happening at all.

I want to figure out how to read the outputs if it is possible.  I think the issue with Coolant is that Mach knows what that is, there is an OEMbutton/Led and Mach has control over it.  I am wondering if I can simply use the UserLED's and turn them On and Off with the actual output that I map to it.  For instance

SetOutBit(90,25) ' turn on my shop vacuum system
SetUserLed(1025,1) ' LED 1025 is now set to 1
.
.
ResetOutBit(90,25) ' Turn vac off
SetUserLed(1025,0)' Led 1025 is now set to 0

Then anywhere else I want to check on a particular output, I just Get the value in that UserLED.  Only trick is to be sure you always change the USERLED when ever Output is changed.  And avoid outputs that Mach has been configured to control.  Will also need to know what happens to UserLed on Mach Startup.  If they persist or even could persist, would need to initialize all of them.

Does this sound like an appropriate way to do this?  Looks like the Reference manual (Page 36 GetUserLed()) is explaining that this is exactly how to do this.

Title: Re: Normally Open VS Normally Closed
Post by: Hood on August 13, 2016, 01:41:18 PM
Did you have that or did you have GetOemLED(13) ?

I presume you are using  the coolant output option in Mach?
What I suspect is happening is you have the Coolant  On, you are resetting the output but the coolant button is still on so Mach switches it back as soon as you switch off.
 That is why I suggested the DoOemButton be used..

Your UserLeds should work fine as long as you only ever turn on/off via that script and not by other means. But do you really need to know? What I mean is if your vac pump requires to be switched off you can reset the outbit and if it is already off it doesn't matter a toss.

Hood
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 03:09:59 PM
Yep, GETOEMLED(13).  That was a typo.  And yes, I enabled the coolant option.

This is not a huge issue except I have things I want to do that are not quite norm for a mill.  In the PLC world, this is easy because it scans the entire program and I am in control of the entire program.  Don't really even need to ask as the only way it could be ON is if I turned it on.

In mach, this is very different.  Coolant function being perfect example.  Mach has control once that option is turned on.  No big deal, just have to deal with that.  So the main idea in this case was to avoid having to turn on and off coolant in the g-code program.  It would have been no big deal to just have my CAM software always add the coolant function before and after tool changes.  And then of course edit program if I didn't really want it on.  Would very much so like to avoid this.

On my machine, I will have an air gun, vacuum, and atleast 3 independant coolant nozzles (6 would be great).  I cut a lot of plastic parts and the chips can be overwelming at times.  Thus the shop vac that is just a suction tube mounted just like the coolant nozzles.  This allows me to suck the chips out as I'm cutting or to make a pass with no tool and clean out pockets and so on.  But 99 percent of the time, if coolant or vac or air gun (or all) was ON before a toolchange, its gonna be ON after the tool change.  But I don't want any of them ON during the tool change (Coolant and compressed air blowing into carosel while its open).  Thus the need to know if they were ON before the change was requested.  I could always just turn them all OFF and require myself to turn the right one back on in the GCode program.  Wheres the fun in that.  I have a programmable controller at my disposal.

Point being, I'm learning how to use MACH.  But with CSLabs hardware, I have a ton of I/O that I want to get real creative with.  I can think of a bunch of cool things that could be done with the extra I/O.

As for using the UserLeds and matching them to particular outputs.  This would allow them to be turned ON or Off, and also just be monitored from any script.  Unless I'm missing something.  A UserLed would stay ON when the script is finished.  And then could be looked at and/or changed later by any other script.  Just have to always do the two step.  Set the UserLed and set the output.
Title: Re: Normally Open VS Normally Closed
Post by: Hood on August 13, 2016, 03:40:32 PM
What I am saying regarding the coolant is you have it set up in Mach as the coolant and Mach is switching the output on/off. So if you have the coolant on and then switch off by VB using the actual Output (ResetOutBit() ) then it will just get switched right back on because Mach is doing that. If your VB used the Coolant Toggle button to switch it off then it would switch off.
So
If GetOemLED(13) Then
 DoOemButton(13)
End If

That should do exactly what you want.

For other things that are not controlled from Mach you should be fine, for example if you wanted the vacuum from a switch you could do it via either a G Code switch or via  a VB switch and also have a custom macro to do it. You could use the User LEDs.


So say you want the vaccum on output 0 of the IP-A  then you could make a custom macro, lets call it m123.m1s.
In that macro you would have something like

If GetUserLED(1111) = 1 Then
 ReSetOutBit(90,0)
SetUserLED(1111,0)
Else
 SetOutBit(90,0)
 SetUserLED(1111,1)
End If


Now if you call m123 from code or MDI it will look at the state of the LED and switch on/off the output accordingly.

Now if you want a screen toggle button to also do this you add a button with one of the screen designers and make it either a G Code button or a VB button.
So for a  G Code button you would add the code you want when in the screen editor, that would be m123.
When you push that button in Mach it will do the m123 macro and do exactly as above.

If you had set the button as a VB button then you would need to add the VB to the button once back in Mach, Operator menu then Edit Button Script. Click the flashing button and the editor will open and you enter the script.
You could have the above script if you wanted or you could simply have
Code"m123"
either will work.


Now if you want an external toggle  button you would use the macro pump to monitor the input your switch is connected to and either have it run the script from within the macropump or have it do the Code"m123"


If you do not want it to be a toggle then you could do things via two macros. One to switch on, one to switch off.


Hood


























Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 03:55:04 PM
I follow you completely.

Thanks for the quick overview as the soft buttons and actual hard switches are next on my list.  Thanks, this will be a good jump start.
Title: Re: Normally Open VS Normally Closed
Post by: Hood on August 13, 2016, 04:42:28 PM
Ok was in a bit of a rush when I wrote that and see that would not be the best for a vacuum table if wanting to operate from G code.

So what you would do is have two custom macros, one to switch on, the other off.

So say m123.m1s for On, that would have

SetOutBit(90,0)
SetUserLED(1111,1)


Now m124.m1s for off, it would have

ReSetOutBit(90,0)
SetUserLED(1111,0)


In either macro there is no need to look at the UserLED state as you are switching on or off from the macros regardless and it doesn't matter if it is already on and you call m123  or already off and you call M124.


Now say you wanted to check from the M6 macro and turn it off if on then all you would do is have the VB to look at the LED state and if On then turn the output off and set the LED off, so

If GetUserLED(1111) = 1 Then
ResetOutBit(90,0)
SetUserLed(1111,0)
End If

Then if further on in the macro you wanted it switched back on you would have

If GetUserLED(1111) = 0 Then
SetOutBit(90,0)
SetUserLED(1111,1)
End If


Now for the screen button, you could have two separate buttons and set them as G Code buttons and have code "m123" in the On button and Code"m124" in the off button, same with panel buttons.
However with the buttons themselves it will likely make more sense to have them toggle buttons so you would just set the screen  button as  a VB button and have the code in the previous post in the button.
Same with the macropump looking at the physical buttons input.


So basically the problem you encountered with the coolant was because you had it set in Mach as Machs coolant where the vacuum is set via VB in all cases, so nothing will force it back on if switched off via VB and vice versa. The only important thing you need to remember is that from any VB you wish to control it from that you also remember to set the state of the UserLED accordingly.


Hood
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 04:57:22 PM
Exactly.

Heres another funny issue.  So coolant is enabled in Mach.  Output 2 on CsLabs.  M8 and M9 control it.

I edited the M8 script and Put in this.
Message "Coolant working"

Simple.  From the Script Editor, I run it and the message "Coolant working" shows on screen and the coolant turns on.  Note I did not have code in M8 to actually turn on the output.  Mach took care of that secretly (and continuously).  Now, I enter M8 in the mdi, coolant comes on but it does not show the message "Coolant working" which means its not running the M8 macro.

My guess, Mach ignored the M8 macro and focused on turning on and off the correct output because it was configured to handle coolant secretly. 

If Mach is doing this, the moral of story is be very careful with outputs that you told Mach to handle.  All those extra inputs and outputs are really unknown to mach and can be controlled.  Until someone tells me I screwed up on this test, I will de-configure coolant and just handle this with M8 script.  Will also help with communication overhead as mach won't be turning on coolant every 100ms or so.
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 05:22:03 PM
As Stirling stated in another post.
Tis What Tis....
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 05:24:21 PM
Damn Hood,
I just crossed the .1 of 1% of your total post count.  Yeah baby....
Title: Re: Normally Open VS Normally Closed
Post by: Hood on August 13, 2016, 05:25:06 PM
I think the M7, M8 and M9 are the real oddball ones simply because it is totally internal to Mach and they have no macros. Things like M3, M4, M5, all have macros and you can customise them to suit.

As an example, on the big lathe I had a 7.5/11 Kw spindle motor which was controlled via a gearbox which had electromagnetic clutches. I controlled these clutches via my PLC and I altered the M3, M4, M5 and Spindle Speed macros in Mach to suit my setup. For example if the  spindle was commanded to switch on and go to 2000rpm I would have the macros step the spindle speed up in increments, changing the clutches as it went, if wanting to go back to zero then the macros  would look at the current rpm and then change the clutches in steps so that I slowed down in a couple of stages rather than just an abrupt stop, same going from a low RPM to a high and vice versa.

Here is a video showing the spindle ramping up at the start  and down at the end via the clutches, that was the days before I had the servo spindle on it.
https://www.youtube.com/watch?v=JvSh6j8x4Gc

Ha ha actually seeing that video is weird as the lathe has changed so much since that initial run, it was via the parallel port so the rapids were, well, not very rapid and the turret had to index one tool at a time and could only go one way, the one I made can index to the next called tool and will take the shortest route.
 Still it was a thrill for me to get it running :)


Hood
Title: Re: Normally Open VS Normally Closed
Post by: Hood on August 13, 2016, 05:29:39 PM
Damn Hood,
I just crossed the .1 of 1% of your total post count.  Yeah baby....

I have been posting here since the forum started (previously was Yahoo only) so have had a long time to post , and learn Mach, think it was still Mach2 back in these days :D


Hood
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 05:44:58 PM
You are dead on.  M8 just don't go no matter what.  Steve Jobs would roll in the grave.  Not that I am an Apple fan, but the man understood and defined out of box experience.

Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 06:17:26 PM
So basically, as often happens, my last 4 or 5 post are crap.  I was testing the M8 function and jumped to a bunch of conclusions.  Thought I would roll on and outsmart the creators.  But turns out if you want M7,8, and 9, you will configure them in Mach Ports and Pins and live with their functionality.  If And But Else, you will write your gcode to use a custom M??? command that's not standard if you don't like it.
Tis What Tis
Title: Re: Normally Open VS Normally Closed
Post by: Hood on August 13, 2016, 06:37:15 PM
There are often other ways to do things, such as, as you say, custom macros for coolant etc.
 For example if you really wanted to have the message in the ticker when coolant was switched on/off then that could still be accomplished. Have the macropump watch the state of the Flood LED and send the appropriate message. The only thing is it would constantly be there unless you could code in such a way that it was just a one shot. I am crap at VB but I am sure others could manage.

Hood
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 06:48:03 PM
I get that.  My Message "Coolant works"  was just a quick troubleshooting "catch".  It worked.  I caught a weird Mach situation, posted to forum, got a response about M7,8 and 9 being "real odd ball".  Worked perfectly.

Theres almost always a work around.  I get that.  One brand has this interface.  Try it.  If what you are trying to do doesn't work, just try it another way.  Every major league brand out there has their issues.  Everyone one of them.

Thats the way it works in any multivendor system.  Documentation is what sets them apart.  And I hate documentation.  Most undervalued "cost of doing business" in my world.  It takes forever and is never done.
Title: Re: Normally Open VS Normally Closed
Post by: Hood on August 13, 2016, 07:40:15 PM
Agree there for sure regarding documentation. It is one of the best things but also one of the hardest things to do right.
Mach changed that fast it was impossible to keep up and documentation writing is an art in any case.
It has to be complex enough to cover everything but also has to be written in a way that is understandable to everyone (within reason). It also needs to be possible to quickly find the section that contains the info you need without having to trawl through hundreds of topics which only partially relate to what you want.
So in essence it is a thankless task and often an impossible task.

I have just been wading through the documentation for the DL06 PLC, it is excellent in many respects but finding what I wanted was hard, especially when I didn't really know what I was looking for :D

Hood
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 07:55:40 PM
Agreed,
I used an Automation Direct drive on this conversion (can't beat the price).  Their documentation on Sinking and Sourcing outputs is dead wrong.  And they only did the one I didn't want to use (sinking output).


Off topic,  Never use sourcing inputs on a drive.  Meaning you connect their drive input signal to ground to make it go.  If a wire gets shorted to ground, off goes that drive.  Maybe that is right back on original topic.
Title: Re: Normally Open VS Normally Closed
Post by: Hood on August 13, 2016, 08:12:28 PM
If my memory serves me right the DL06 can be set either way (in banks of 4) . For me I like Sourcing outs and Sinking Ins, just seems natural that way :D

Seems to be a lot of the Asian servo drives like to have sourcing Inputs, why I have no idea but it is often a PITA and as you say can be dangerous.

Hood
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 08:45:59 PM
The asians got this one wrong.  As I stated earlier in this post, safety requires forward thinking.  If a wire gets cut- we should predict the state.  No sane person won't understand that a wire that got cut will very likely go to ground or be cut clean......  It could short to another hot wire but the odds are stacked way against that.

So, when the asian drive folks opt for grounding the input to make it run, they clearly haven't progressed through the lawsuits.

Most PLC's can do the bank of X number of inputs or outputs.  For example, Inputs 0-3 may share the same "common" (not to be confused with DC Com).  If you connect the DC Common to this terminal, this provides a path to ground or specifically DC Common.  So if 24 VDC shows up on any one of 0-3, it will allow current to flow to the "common" terminal because you connected DC Common or ground to that terminal. Howerver, if you hook up 24vdc to the common terminal.  In that case, when you apply 24 vdc to one of those inputs (0-3), no current will flow because 24vdc is on both sides of the circuit.  The Input will not be activated.  In the same setup (24 on the common),  If you ground or connect dcComm to one of the inputs, current will flow "backwards" (thats highly debatable) and the input will register.

It is very useful to have banks of inputs that are selectable for sinking or sourcing.  Case in point is the Automation direct drive I have.  It will only provide a sinking output (meaning it provides a DC Common when ON).  The only way to use this directly is connect 24vdc to my "common" for some output and let the drive provide a ground or DC Common.  This will activate the input.  This is why CSLabs has all those dedicated connections for each input.  If, Like PLC manufactures generally do, they banked 4 at a time, I would waste 4 inputs if only one of my inputs required a sourcing input (meaning current needs to flow out of the input- to the drive------highly debatable again).


Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 09:11:12 PM
To simplify the safety issue.

Imagine standing in front of your machine.  Floor is wet, you happen to be barefooted today with bud lite in your left hand.  You reach out and turn a simple switch to make something go.

Switch is an old/current barrel type swicth that is really a fwd/rev switch that is wired 3 phase 480 volt.  Your spilled bud lite has grounded your bare feet.  That high voltage is 1 inch behind the aluminum face plate you made.  But, your spilled beer has bonded you (like it or not) and there is actually a clean path from the barrell switch contacts to ground through you fingers and bare feet.  NOT GOOD.

So, many years ago, it was figured out that it is much safer to remove high potential voltages from operators.  Two things happened and two thought paths occurred.

Lets only have the neutral or ground (most neutrals are grounded) on the switch panels.  Sounds great.  If you are standing in water and touch a switch that can only provide ground, no current can flow.  Perfect.
Except that, now when wires get damaged, the likely hood is they go to ground and activate the signal. Not so perfect.

The other thought (And I agree with this one) is to minimize the voltage potential at the operator switch.  At first, 120VAC was good enough.  Now we want lower voltages and DC would be good.  So, 24vdc is the standard.  It is really hard to die (or even notice) while touching a switch that is powered by 24vdc with an appropriate circuit breaker (don't forget that one).
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 09:19:54 PM
Wow..l Sound like an old dude.  Kinda sux.
Title: Re: Normally Open VS Normally Closed
Post by: Mike VT on August 13, 2016, 09:24:08 PM
The asians got this one wrong.  As I stated earlier in this post, safety requires forward thinking.  If a wire gets cut- we should predict the state.  No sane person won't understand that a wire that got cut will very likely go to ground or be cut clean......  It could short to another hot wire but the odds are stacked way against that.

So, when the asian drive folks opt for grounding the input to make it run, they clearly haven't progressed through the lawsuits.

Most PLC's can do the bank of X number of inputs or outputs.  For example, Inputs 0-3 may share the same "common" (not to be confused with DC Com).  If you connect the DC Common to this terminal, this provides a path to ground or specifically DC Common.  So if 24 VDC shows up on any one of 0-3, it will allow current to flow to the "common" terminal because you connected DC Common or ground to that terminal. Howerver, if you hook up 24vdc to the common terminal.  In that case, when you apply 24 vdc to one of those inputs (0-3), no current will flow because 24vdc is on both sides of the circuit.  The Input will not be activated.  In the same setup (24 on the common),  If you ground or connect dcComm to one of the inputs, current will flow "backwards" (thats highly debatable) and the input will register.

It is very useful to have banks of inputs that are selectable for sinking or sourcing.  Case in point is the Automation direct drive I have.  It will only provide a sinking output (meaning it provides a DC Common when ON).  The only way to use this directly is connect 24vdc to my "common" for some input and let the drive provide a ground or DC Common.  This will activate the input.  This is why CSLabs has all those dedicated connections for each input.  If, Like PLC manufactures generally do, they banked 4 at a time, I would waste 4 inputs if only one of my inputs required a sourcing input (meaning current needs to flow out of the input- to the drive------highly debatable again).