Machsupport Forum
Third party software and hardware support forums. => SmoothStepper USB => Topic started by: kid on April 28, 2012, 01:51:05 PM
-
I had Mach system running thru parallel port with serial modbus from DL06 to control inputs/outputs and limit switches. Old computer with parallel port died. So i decided to upgrade to new computer with Windows 7 and go with Smooth Stepper plug-in. Everything seems to work but limit switches, I see the LEDs change state but no function. what I mean is: During testing if an axis is running (say X) and i trigger a over travel limit switch (X++) nothing happens, LED lights but axis keeps running. DL06 sends it, Mach gets it but Smooth Stepper seems to ignore it. Any ideas, or am i missing something in my configuration.
-
Never tried running the limits into Mach via the PLC. I do however put my limits to the PLC but they dont actually go to Mach as limits but rather an e-stop signal. I have all my limits along with drive fault signals etc in the ladder set up so they send an E-Stop to Mach, they also are in another rung taking the enables away from my drives.
I dont see why it wouldnt work the way you have it set up but would have to test and afraid I dont have a PLC here at home.
Hood
-
Thanks for your response Hood, That's a good idea with the logic. I think I will have to do the same thing.
After some testing and curiosity I also checked some other Mach pin inputs. Home limits will not work either and you also get a SS message pins not assigned to SS.
But..... ESTOP does work??? So that means SS can see them.
When I get time I will play around more, But for now changing some logic should get me back up and running.
Thanks again, Kid
Please post if you find out anything.
-
I have just looked at a ladder and I was misspeaking, sorry. I have the output from the PLC going into an input on the controller as an E-Stop signal so it is not going via modbus.
Will try and test things out today for you. Below is a sample of the E-Stop string I have on the Scorpion which is basically a slightly grown up version of the SS.
Hood
-
Ok just grabbed the PLC and did a simple ladder with two inputs that then go to Mach via Modbus. I set one as a limit in Ports and Pins and the other as E-Stop. E-Stop works fine but as you found the limit is ignored. When I say E-Stop works fine, it does with the exception of the annoying message that no E-Stop is configured for SS, this is even with the option not to report pin errors in the SS plugin. It wouldnt be too bad I suppose but occasionally it pops up under Mach and there is nothing in the taskbar letting you know it is there and you can wonder why Mach will not reset. It is only when you minimise Mach that you see the message underneath it, real PITA.
Hood
-
I have also just tested with a modbus input to a brain which should activate the limit switch, it does but SS again ignores. Looks like the E-Stop is the only way.
Hood
-
I had Mach system running thru parallel port with serial modbus from DL06 to control inputs/outputs and limit switches.
in general this is a really bad idea. Signals like limit switches, home switches, EStop, etc, should NOT be run though a PLC or any other sort of external device. They must be hooked directly to the motion controller (i.e. parallel port or SmoothStepper) to work properly. You have a LOT of I/O with the SmoothStepper so you can wire up your limit switches to it directly.
-
Have to sort of disagree with that Jeff, it all depends on how you are handling things. I agree 100% if you are simply passing the signals via the PLC to the software then it is best to do it via the motion controller. Doing it via the PP probably makes little difference as it would then be relying totally on software no matter whether they went via Modbus or in via the PP.
My preference is that the signals from limits, E-Stop etc are handled in the PLC which drops out enables or contactors etc and then the signal is also passed on to Mach via Modbus or Controller.
Hood
-
My preference is that the signals from limits, E-Stop etc are handled in the PLC which drops out enables or contactors etc and then the signal is also passed on to Mach via Modbus or Controller.
Do I understand this correctly that you are passing E-stop to Mach thru modbus? I am curious about that because I am sort of wrestling with that whole concept right now.
-
My PLC's take the E-Stop, Limits, Drive Fault signals etc and take away the enables from my servo drives if iany of these are seen, that is on one rung of the ladder. There is another rung that also uses the limit, Estop, Faults etc and this operates a relay output on the PLC and this goes to Mach via the controller (Scorpion or SS or ESS) as an E-Stop input to Mach.
Because my limits do not go to Mach I have a button on my panel which can override them so that I can jog off a limit. See pic of rung in previous post and also the other in this.
My E-Stop switch also drops out all the contactors that control motors.
Hood
-
OK, it does not appear that you are going thru modbus with your e-stop. Sounds like you are hardwired to the BOB (be that an SS or whatever).
My setup is similar except that I do not go thru a PLC. I have an E-stop 'collector' board that has 4 inputs daisy chained and one out put. Any input goes out the E-stop goes out.
I have only been using MACH modbus for a few months and I don't trust it very much. Seemed scary to run E-Stop thru it.
Thanks for the info.
-
I could just as easily go via Modbus to Mach and in reality it would not be much (if any) less safe, the reason is as far as my machines are concerned the E-Stop to Mach is just a signal telling Mach to e-stop and thats about it as the rest of the E-Stop string is taken care of in Hardware via contactors etc.
Jeff mentioned earlier that putting limits etc via Modbus is unsafe and I agree with him if that is the only means of stopping but even going direct to the controller with them could still be deemed to be unsafe as you are still relying solely on software to E-Stop on a limit.
Hood
-
In my view, you are relying on software no matter how you arrange it. Mach is software.
Modbus is an old standard which one might assume was intended for and addressed a specific purpose when it was developed. However, now each device implements that standard, or more typically portions thereof, taking various degrees of license as they do. Mach is only one of many.
Even if you set the reliability question aside (probably just me being typically paranoid, yes?), you still have two serious risks with modbus, one being the slow refresh rate and it's tendency (in my experience thus far) to 'skip' cycles altogether. There is pretty much a guaranteed lag time which is not a good thing for an E-stop function. However, the most scary characteristic is that if it doesn't like something it just throws it away. What if that crunched up data packet in the circular file was your E-stop?
I may not have the operation of MACH modbus entirely accurate in my mind, but it is proving very difficult to get any useful information on it. Doesn't seem to me that I know enough about to be asking any really tough questions, yet . . . . I am beginning to get the impression that few if any really have a thorough understanding of it, or at least of the fragment of it that is implemented in MACH. Perhaps it is best left to the inconsequential applications it is typically used for.
-
I am not relying on Mach at all for limits or E-Stop. Limits are handled by the PLC internally and E-Stop is handled in the PLC but also via the second pole of the E-Stop switch cutting the power to the contactors which in turn cuts the power to my drives etc. The only thing Mach is doing is getting a signal and throwing an E-Stop for itself. If Mach didnt get my E-Stop signal then it may happily think it was carrying on machining but my servos would have been stopped by hardware and would not be doing anything that Mach was telling them to do.
Having said that Modbus has been totally reliable for me, I have never had a problem, most of my buttons on the control panels go via it, my lathes turret also goes via modbus, coolant on/off etc etc and not once have I seen a problem, possibly it is the hardware you are using that the problem lies with?
Hood
-
My comment on software was generic. A philosophical observation. Zen CNC ;)
However, I am reminded now of an important question related to 'external' E-stop schemes. First let me say (again genetically, not directed at anyone) that to suggest 'kill the power to the drives' as a stand alone blanket statement, is good advise only if that advice ALSO explains the cosequenses and how to deal with them.
For example, I've seen diagrams with contactors between a linear power supply and DC drives. You and I would know better than to re-close that contact before those big caps bleed down, but a noobee could loose all of his drives in a split second. I've read advice to put the cutoff between the drive and the motor, with no mention of braking the motor. What you have there is a 'coasting' axis or spindle. By following 'kill the power' advice, the user has inadvertently removed the drives ability to stop the motor, thereby creating a far more dangerous situation.
So my question is, where to you cut the power and by what mechanism do you stop the motors. I am curious myself and I think it would be good for readers to know that 'kill the power' is only half of the story.
-
Having said that Modbus has been totally reliable for me, I have never had a problem, most of my buttons on the control panels go via it, my lathes turret also goes via modbus, coolant on/off etc etc and not once have I seen a problem, possibly it is the hardware you are using that the problem lies with?
I am not actually having a 'problem' with modbus. What I am using it for now are the type of functions typically described, pendands, as well as the functions you mentioned. It is not particularly serious is it if the coolant shuts off a quarter of a second later that it should have? If you push a button and nothing happens, you just push it again. If a few steps from a pendant wind up in the trash, no biggie.
Having read the spec and learned a bit about modbus, together with my couple of years experience with MACH and 30+ years of experience with digital processes in general, I am trying to asses whether it is wise to rely on MACH's implementation of modbus for anything critical. Certain people have my ear; you are one of them certainly. Another is Papabear. He wrote recently not to use Modbus for axis motion as the refresh rate is too slow. Good advice, I recon. Somewhere between 'Do not use it' and 'It is totally reliable' is quite a range. I am leaning toward 'do not use' for critical functions. My new motor controller talks to Mach continuously over Modbus, for example, but the E-stop is hardwired from the controller to the BOB in both directions. I am using a Brain to get the Estop from MACH to the BOB pin, but Brains are extremely fast and even if they skip a beat (which seems unlikely) it would be inconsequential.
You did not answer the question about Modbus lag time in terms of using it for E-stop. That would be high on my 'nervous list'. A lot of bad stuff can happen in 40ms.
-
Scott is right, modbus in Mach is no use for time critical use so if that is what you will be trying forget it, it was not meant for that but just rather to add general purpose I/O to Mach.
Regarding the E-Stop, I have mine via my controller (Scorpion or SS or ESS depending on which machine) but as said it would not matter a toss to me on my machines if it did go via modbus and had a ten minute delay. The E-Stop input to Mach on my Machines is primarily to inform Mach that an E-Stop situation has happened and not for Mach to call an E-Stop. Relying on software to call an E-Stop is not safe to me and is not what I do but others do and are happy that way.
Regarding the way I do things, I was being specific about my machines and my hardware and not being "generic" ;)
You have to obviously do what suits the hardware you have.
Hood
-
Oh just better mention something else, Brains are fast but that is just internally in the brains, they still communicate with Mach at its refresh rate (10Hz at the moment) so in reality are no faster than a macropump.
Out of curiosity, which Modbus are you using?
I use serial Non-Plugin as I cant see any benefits to using the plugin variant and actually there is a disadvantage in that you cant directly set up the inputs/outputs of Mach with port and pin numbers for modbus if using the plugin, in fact I am not even sure if the modbus I/O can be set/read in VB when using the plugin. Both of these can be done if using the non plugin serial interface.
Hood
-
I ran into the same issue you described so I am also using non plugin serial. Some of the VB macros manipulate the registers directly and relacing all of that with brains or whatever would be a lot of trouble with little benefit since the plug-in modbus is no better in the aspects that are important to my app.
Now then . . . I had no idea the brains were that slow! They seem extremely fast to me. I pull Z or Y axis position from Mach and use it to calculate the 4th axis RPM based on the SFM the user wants. Just based on visually observing the update rate (i.e. how many steps are in the RPM delta), the brain seems like it is real time. By the time the data slogs thru Modbus, it is in sort of big chunks, but the brain itself seems to be breathing in data very fast. I'll need to look at that again.
One of the workarounds I mentioned was to take two data chunks from modbus, say 150RPM and then 220RPM and calculate 8 to 10 'tweens' to provide a much smoother transition while waiting for the next chunk. So I am actually intoducing some lag outside the modbus, but the 4th axis arriving at commanded RPM 40ms late is incosequential. The controller then sends the 4th axis current RPM data back to MACH for display on the MACH screen. So there is a real world example of one of my current uses of modbus.
There is some documentation somewhere that implies that TCP modbus can access vaiables, and there are separate commands juts for that . . . . but none of the commands actually work, so no help on that front either.
-
It may be that the Brain can communicate directly over modbus at the Brains speed, I dont know. I do know however that anything going to Mach from a Brain is at the 10Hz update of Mach, or at least thats what I have been told on several occasions by the high heid yins.
Hood
-
Everything over modbus is at modbus speed, no matter how fast the brain is.
But if you were using a brain for somthing that did not involve modbus, you would get full brain speed . . . . whatever that may be.
Incidentally, Mr Hood, you never did say how you stop your motors after killing power. Inquiring mindes want to know. My setups are not much different than your except for brand.
-
My drives have internal shunt circuitry so that is one part of it, the spindle motors have brakes, the axis have friction, when I hit E-Stop things stop dead, in fact I dont like doing an E-Stop when things are moving at 10m/min on the lathe, 500Kg plus stopping dead puts strain on things, but sometimes it has to be done ;D
Hood
-
Brakes are easy enough to understand. I have brake motors on some axis, some not. Not a conscious decision, just whatever motors were available at the time. My spindle has a fairly stout disk brake that I added using the caliper from the 4th axis . . . a bit of overkill there. It is solenoid driven pneumatic, but I do not have it set up as sailsafe. Probably be a god idea to do that.
Since you mention shunting in the drive, I will assume that you do not cut power between the drive and the motor.
On the Mistu, you can feed the electronics separately from the power side of the drive so you can remove power and the drive still stay 'awake' and can stop the motors, in which case, cutting the power would be for safety and not as the sole means of stopping the motors. I think that is the smart way to set it up.
The Mistu has separately configurable decel on loss of power and also configurable behavior of power up after a power loss. All very good features.
We are some distance off topic here, so I'll get back to work now. Nice chatting with you again.
-
No, motor to drive is always connected and yes my drives have standby power for the logic. Another thing you may want to look at is to see if you have fwd and reverse overtravel inputs.
Hood
-
Yes, there are limits in the drive. There is probably a 'bring me coffee and toast' command :D, . . . however, I don't even have limit switches on the mill yet :-[
I built the mill for a specific project and only had time to get it finished enough to do the project. Just too busy to finish it out. When I do get some time for my own stuff, I would probably spend it building my new 'permanent' mill. There are stacks of steel and ball screws and slides all over the place, I just need a stack of time.
I take it you use the limits in the drives rather than MACH. What is the advantage? I'm thinking about messing with a linear encoder. Not sure if I can do that with the Mistu.
-
What I am getting at is you can wire an input up and configure as both Fwd and Rev over travels and have that in the E-Stop string and your drives should stop instantly. It may not be possible on your drives to set multiple functions to one input but on mine it is. Would also have to make sure that you have shunt circuitry in your drives, so they can dump to the shunts.
Hood