Messages

31

General Mach Discussion / Re: Normally Open VS Normally Closed

« 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.

32

General Mach Discussion / Re: Haas VF1 Conversion

« on: August 13, 2016, 09:33:39 AM »

This makes perfect sense.  I probably made stupid assumption thinking about modbus with coils and registers and then seeing the "bit" in GetInBit.

So I think you are saying that I should never have this:
If GetInBit() Then...

But instead, it should be

If GetInBit()=1 Then...


Thanks, I think this helps alot.  Don't think I ever looked at what Type anything was.  Thats not cool at all.

33

General Mach Discussion / Re: Normally Open VS Normally Closed

« 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?

34

General Mach Discussion / Re: Normally Open VS Normally Closed

« 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.....

35

General Mach Discussion / Re: Normally Open VS Normally Closed

« 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.

36

General Mach Discussion / Re: Normally Open VS Normally Closed

« 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.

37

General Mach Discussion / Re: Normally Open VS Normally Closed

« 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.

38

General Mach Discussion / Re: Normally Open VS Normally Closed

« 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.

39

General Mach Discussion / Re: Normally Open VS Normally Closed

« 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.

40

General Mach Discussion / Normally Open VS Normally Closed

« 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.