Hello Guest it is March 28, 2024, 02:01:05 PM

Author Topic: Normally Open VS Normally Closed  (Read 20323 times)

0 Members and 1 Guest are viewing this topic.

Re: Normally Open VS Normally Closed
« Reply #10 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.
Re: Normally Open VS Normally Closed
« Reply #11 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
Re: Normally Open VS Normally Closed
« Reply #12 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.

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Normally Open VS Normally Closed
« Reply #13 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
Re: Normally Open VS Normally Closed
« Reply #14 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.....
Re: Normally Open VS Normally Closed
« Reply #15 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?

Offline Davek0974

*
  •  2,606 2,606
    • View Profile
Re: Normally Open VS Normally Closed
« Reply #16 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

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Normally Open VS Normally Closed
« Reply #17 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 )                                 
                   




Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: Normally Open VS Normally Closed
« Reply #18 on: August 13, 2016, 05:49:56 AM »
Re: Normally Open VS Normally Closed
« Reply #19 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.