Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Dan13 on February 19, 2013, 02:15:12 PM
-
Witnessed a very strange behaviour today - a potential cause for a disaster! It's on a lathe which does homing internally in the drives and sends back a command that it finished. To send a command to the drives to start homing we used User LED's in Mach which we turn on in the homing buttons and a simple Brain sends the LEDs state to the drives. LED ON -> Send command to drive -> Start Homing -> LED OFF.
Want happened today was the LED's going high when opening the wizards from the top menu, selecting threading wizard and clicking OK. As soon as OK is clicked, LED's go high and drives start homing. This is repeatable and happens each time exactly in the same way. How does it happen?! How is it that simple to UNINTENTIONALLY change the state of LED's?!
Dan
-
What version of Mach?
Is it Simple Threading?
What LED number?
Hood
-
Hi Hood,
Mach version .062.
Simple Threading Wizard. Normally, unless you installed additional ones, there are only two in the list - Simple Threadin and Turning. I probably should have checked the Turning one as well, but I didn't. I reckon it would be the same with that one as well.
LED numbers 1003 and 1005.
In the mean time we added a safety feature - a hardware button that goes directly to the PLC and the PLC would wait for both that button and signal from Mach to start homing. Don't think we would revert this and use merely the signal from Mach as we can't trust it anymore after seeing this happen. Who knows what else could then trigger those LED's. What if it would happen with a boring bar inside a part!
Very, very strange and scary!
Dan
-
Ok I am getting that as well, as soon as I load any wizard the LED state must be changed,will have to look at it later to see if I can figiure pout why.
Curious why you are using a LED state to operate the homing? Can you not just call an output from VB and wait for an input instead of looking at LED states?
Hood
-
Using LED's for that since I don't know of another way. Talking to the PLC over Modbus with Plugin Enabled and as such it doesn't allow sending outputs from VB and reading inputs. Unless I am doing something wrong of course.
Dan
-
Ah ok, that is one of the ptfalls of using the plugin.
I have asked a few people what the benefit of the plugin is and not had an answer, all I see is lacking of functionality with it but there has to be a benefit somewhere or why use it?
Hood
-
Honestly, I don't know. Was just reading some posts by Scott (poppabear) where he strongly recommends using the plugin. Thought he must know something. Think without the plugin it's not stable or reliable...
What are the commands you're using in the VB? SetModOutput and GetInput? Also not sure how to work with the non plugin Modbus. Information seems to be lacking. Can you use Brains too with the non plugin version?
Dan
-
I asked Scott what benefits there were to the plugin and dont think I got an answer.
As for not being stable then I would dispute that, have never had an issue with the non-plugin serial modbus in all the years I have used it, it has been extremely stable and reliable.
Yes you can use it in Brains, can also use from VB and also use direct in Ports and Pins.
Yes VB is as you state.
Heres a screenshot of my Modbus page.
Also CSMIO can use modbus for inputs and I was a bit worried it would be a problem seeing as I am using it for the PLC but on the one thing I have tested, encoder module input for height setter, it works fine.
Hood
-
This sounds good! Still not sure how to work with it. See the screenshot. How do you do the same in the non plugin version? Accessing numerous different addresses in the slave?
Is it a screenshot of your actual machine settings? You're using 8-1-N, while Scott strongly suggests 8-2-N.
Dan
-
I am not sure if you meant to attach a screenshot or not but dont see one if you did?
That screenshot was from this desktop computer but below is the actual screenshot from the big lathe. And yes I am using 8-1-n not sure why but just what I have always had set and no issues.
You set the start register and then it will look from there, for example I have the first as 1025 (2001 Octal) and I have 4 registers set. I am also using the bitmapped (bitpacked?) option so the PLC has something like the following in it.
B2001.0
B2001.1
B2001.2
......
b2001.15
b2002.0
b2001.1
....
etc
So say for example I want to read b2001.1 from VB it would be GetInput(1) or B2002.0 would be GetInput(16)
Also I could set them up in ports and pins to an input, the ones above would be Port 0 pin 0 and Port0 Pin16
Outputs are the same idea
B4000.0 etc etc
and setting from VB would be
Set ModOutPut(0,1) or (0,0) depending on whether you are turning it on or off.
Likewise in Ports and pins you can set the outputs as port 0 pin 0 etc
Hood
-
LOL... got distracted and forgot the attachment.
Still this one has the addresses spread on a wider range than I could do with the non-plugin Modbus. Or, I hope, I am wrong.
Dan
-
I am not sure Dan, never looked at the plugin interface any more than I am doing now by looking at your screenshot, it just confuses me ;D
As for inputs, the first start register allows 64 inputs (0-63) and also 64 on the second (64 to 127) Same for outputs. Not sure if that was what you were meaning?
On the first one I have 4 registers enabled so that allows me the full 64 , on the second I also have 4 but as it is not bitmapped then that is just 4, that is my analogue inputs on the lathe.
Hood
-
You can only access consecutive addresses in the PLC from what I see. In the above screenshot (taken from Scott's manual, by the way) you can see that different addresses in the slave are being accessed: 2000, 1000, 5000, etc.
Also can have several slaves at the same time (PLC, two servo drives and a VFD).
Please correct me if I am wrong with any of the above
Dan
-
FWIW I delved into the non-plugin vs plugin thing here www.machsupport.com/forum/index.php/topic,20234.0.html (http://www.machsupport.com/forum/index.php/topic,20234.0.html)
I came away with the view that as written, the plugin version has the ability to address more than one RS232 slave without needing an RS485 interface (Port/Address on the setup screen you've just posted) whereas the non-plugin version is limited to just ONE RS232 and so you'd absolutely need RS485 to address more than one slave (ignoring the creative use of diodes for short distances).
I wanted to do this because my THC uses modbus and I wanted it to be able to sit along side any other modbus devices the user might already have (a pendant for example) without needing RS485.
All sounds great but there's just one problem... Mach doesn't have the ability to use that multiple RS232 functionality provided by the plugin..... or at least that's how I understood it ;D
That said - I may be barking up the wrong tree - but the problem here seems to spring from the use of USER LEDs that are used by another process (i.e. the wizards in this case). Couldn't you just stick with the system you have but use the standard system homed LEDs instead of USER LEDs?
Ian
-
Hi Ian,
We are talking to 2 slaves with the plugin Modbus at the moment with no issues, Using a RS232 to RS485 interface.
I am using User LEDs only to command the start of homing to the drives. You are not allowed to change standard LED's state at will so User LEDs were the way to go.
Dan
-
Hi Dan
We are talking to 2 slaves with the plugin Modbus at the moment with no issues, Using a RS232 to RS485 interface.
Err yes - that's what I said. ;D
I am using User LEDs only to command the start of homing to the drives. You are not allowed to change standard LED's state at will so User LEDs were the way to go.
Err - yes again - I understand that. ;D
But consider this: What happens on a STANDARD Mach setup that DOESN'T have home switches when you hit the STANDARD Ref All Home Button?
Because you home in the driver doesn't that mean that as far as Mach is concerned it DOESN'T have home switches?
And therefore....?
Ian
-
Ah... yes, Mach thinks there are no home switches. But I can't use this as I am doing Button(22) or Button(24), for X and Z respectively, AFTER I get a confirmation signal from the drives. So the buttons above set the Machine DROs to zero and the standard Mach3 LEDs for homing are lit.
Dan
-
Ah I see what you are saying now Dan.
Hood
-
Hood,
Are you not doing it the same way? Thought we had been on the same page.
Dan
-
Ah... yes, Mach thinks there are no home switches. But I can't use this as I am doing Button(22) or Button(24), for X and Z respectively, AFTER I get a confirmation signal from the drives. So the buttons above set the Machine DROs to zero and the standard Mach3 LEDs for homing are lit.
Dan
I'll go a bit slower.... ;D
OK so you don't use the STANDARD ref all home button - it doesn't matter - just go with me on this for a second...
At the moment - you tell the drives to home an axis (pick an axis - any axis) and as you say, AFTER they're homed you then you do a doButton(22) or (24) which puts Mach in the "home" state. yes?
What does it matter whether you tell Mach AFTER or BEFORE? All you're doing is getting the physical hardware and Mach to be singing off the same hymn sheet. i.e. when your machine's homed Mach is "homed" - who cares which one did it first as long as they both are "homed"?
Sorry if I'm missing something but it all seems dead simple to me ;D
Ian
-
Dan I home externally but I use VB calls not LEDs.
Hood
-
Ian,
You're right, it doesn't matter who does the homing first. I just feel more comfortable having the drive finish its task and then allow Mach to take control over. I agree though that the end result is the same.
Dan I home externally but I use VB calls not LEDs.
Hood
And you don't use buttons 22, 23,, 24?
Dan
-
Fair enough Dan.
BTW - if you don't mind me asking - did you build your RS485 yourself or is it out of a box?
Ian
-
The RS485 is out of a box, Ian.
Dan
-
Yes Dan I use them but not User LEDs.
Heres my button script
DoOemButton (240) 'De-Reference All axis
Sleep(10)
If GetOemLED (809) Then 'Check that Ref Z LED is RED
Do
Call SetModOutput (21,1) 'Activate ModOutPut 20
If GetInput(19) Then Exit Do 'Loop until ModInPut 18 is seen
Sleep (10)
Loop
End If
Call SetModOutPut (21,0) 'DeActivate ModOutPut 20
DoButton (24)
etc etc
Hood
-
Just bought a RS485 to connect the new servo drives I have to their config software, its working well and price wasnt too bad :-)
http://www.ebay.co.uk/itm/280710974444?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649
Hood
-
Thanks for the snippet, Hood. I don't understand your first If statement. You first de-referenced the axes and then you're checking if it's really de-referenced? Why? Also, the conditional is not clear to me - your checking if LED 809 is active? Should it be '1' when red? Just tried to map it to a DRO and it's showing -1 for red and 0 for green.
The Do loop is interesting. Didn't know you could use such syntax to exit the loop. Will read the manual about the Do loop. Was always using While loops.
Dan
-
I am looking at the state of the Ref LED for starting the loop so I have to de-ref first step so that it is in the correct state.
The Red for the homed LEDs are seen as active state, green inactive (if thats proper terminology ;) )
I have used the DoLoop for years, first used it on the big lathes turret, found it in a VB for dummies book I think, which incidentally is still too advanced for me to read and understand
Hood
-
I am looking at the state of the Ref LED for starting the loop so I have to de-ref first step so that it is in the correct state.
The Red for the homed LEDs are seen as active state, green inactive (if thats proper terminology ;) )
Not sure I understand. Still think it would work even without that If statement...
I have used the DoLoop for years, first used it on the big lathes turret, found it in a VB for dummies book I think, which incidentally is still too advanced for me to read and understand
;D afraid we are in the same boat there.
Dan
-
Yes Dan it would work fine without the If statement, at the time I thought I would need it but have since done some without and they work fine. Just dont change what works is my motto :-)
Hood