Messages

631

SmoothStepper USB / Re: smooth stepper and modbus I/O

« on: May 18, 2012, 08:27:17 AM »

Yes, there are limits in the drive. There is probably a 'bring me coffee and toast' command  ,  . . .  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.
 

632

Modbus / Re: Modbus and Timing

« on: May 18, 2012, 07:46:41 AM »

But then it wouldn't be the MODBUS protocol it would be something else. Remember anyway that in MODBUS there can be ANY number of slaves - what would you do? have an interrupt line from the master to each and every slave?

I have made a decision about using MACH modbus, but I will address your comments, since you were good enough to respond.

The master could certainly generate an error indicating which slave did not respond, but as you point out, it is what it is, and it is modbus.  Unfortunately, saying anything that is percieved as negative against MACH around here is like you're insulting somebody's sister or something. I'm not trying to change modbus, and I am not bashing MACH.  Just trying to find out what is and is not available in MACHs implementation, which for example is not the entire Modbus set. That is important stuff to know if one is going to use MACH modbus, you would agree?  Documentation is next to none and what does exist is often contradictory (TCP variable access, for example). So again, it is what it is, and you need to try to get info from a support forum.

In any case, one 'interrupt' line would be enough. One E-stop line is enough, yes?

Mach has one E-stop monitor available to the brain, which I rout to a physical pin. From that pin, I can do with it as I need, with as many devices as I need.

Also if your concern is that the master may "die" you'd have to monitor that with a third party (watchdog) anyway - something that's died can't tell you it's died.

I don't think I said the master would die. I said if anything goes wrong with the com. as you noted later in your post. Something that dies can definitely tell you it has died. That is called failsafe and is the purpose of the default charge pump, is it not?

I've looked at your other thread and if I've understood you correctly you're concerned what happens if the master "dies" for some reason then just have a brain (your watchdog) monitor a master/slave heartbeat reg/flag. That will tell you not so much whether the master has died or a slave has died - just that they're no longer playing catch for whatever reason.

It is the entire com link, not just the master as noted earlier, but the master seems like the logical place to monitor from. Most of the time it is my software causing the problem, so what I want to know is if it has responded to the master. Hard to know that from the slave end.

As I said in those other posts, I am already timing the loops so I can see if the 'game of catch' ends, but only after a delay and it would be a guessing game in any case because the loop times are not consistent.  I am not sure why that is yet. Could be a bunch of different causes. I would need to wait until after the longest historical loop time passed before having confidence that there is an actual problem. The master would be the best place to snoop on things because it knows quickly if there has been no response.

"have a brain (your watchdog) monitor a master/slave heartbeat reg/flag."

Is there such a thing as a heartbeat flag? That would do the trick. This is what I asked at the beginning and have gotten no answer to. Where is the heartbeat flag. Modbus times out, but nobody knows if that event is available in MACH, so I have assumed it is not. 
Ian
[/quote]

633

SmoothStepper USB / Re: smooth stepper and modbus I/O

« on: May 18, 2012, 06:44:46 AM »

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.

634

SmoothStepper USB / Re: smooth stepper and modbus I/O

« on: May 17, 2012, 05:29:15 PM »

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.

635

General Mach Discussion / Re: A Power Drawbar Like No Other....

« on: May 17, 2012, 04:53:44 PM »

A 30 series holder should run at about #800 - 1000 drawbar force.
30 series?    BT30, CAT30, ISO30, NMTB30   are you suggesting they are all the same? I don't know if they are or not, just asking.

A r8 collet holder made need a great deal more to hold a tool in the collet for heavy cutting. Solid tool holders require less (;-)

Certainly a lot less to hold the tool, but transfer of torque from the spindle to the R8 taper would be the same, one would think.


THE drawbar force based on torque is a guess. It depends on thread pitch , friction AND the strength of the drawbar as to generate force it has to stretch to hold force on the toolholder.

Those would be the 'couple of other params' I mentioned. of all the factors to consider, only friction is a guess. Material strength is irrelevant . .  unless the bar breaks or strips    1000lbs is 1000lbs regarless of how much the bar stretches to transfer the force.

A machine like Dave Dec used with a simple one piece spindle is simple to do what he did drawbar wise . Don't think it would work on a Kneemill setup very well.  THE tool holder claw idea worked very well for him and the use of the modified cat30 holders allowed him to GRIP the tool holder with the ATC and get spindle/tool  indexing correct.

Dave Dec again . . can anyone provide a link?  Why would you need to modify cat30 for an ATC  . .  isn't that sort of like a Ferarri modified for the Autobahn?      Don't they come out of the box ready to rock?

 

636

SmoothStepper USB / Re: smooth stepper and modbus I/O

« on: May 17, 2012, 04:32:39 PM »

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.



 

637

SmoothStepper USB / Re: smooth stepper and modbus I/O

« on: May 17, 2012, 08:49:31 AM »

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.

638

SmoothStepper USB / Re: smooth stepper and modbus I/O

« on: May 17, 2012, 08:33:47 AM »

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.

 

639

General Mach Discussion / Re: A Power Drawbar Like No Other....

« on: May 17, 2012, 07:41:14 AM »

It hjas been pretty well established at this point that to use TTS to its full capability (which I do every day), requires upwards of 2500# drawbar tension, or 25+ ft-lbs drawbar torque.  

Funny you mention that. I offered to help a guy who was trying to figure out the force needed. I told him to use a torque wrench to tighten his drawbar and give me the number and a couple of other params and I would calculate the force for him. His response was that "you can't calculate force from torque". Sounds like you have this figured out though.  

That's hard to achieve without a really large pneumatic cylinder, a multiple-piston cylinder, or an air over hydraulic system.  Then there's the headache of packaging on a knee mill, where the Bellevilles either have to fit inside the spindle, or you need to build some kind of holder for them above the head, which is a major PITA.  Hence my decision not to go that way.

Obviously, you have been doing some homework on this. An articulated multi piston pneumatic cylinder can generate the 2500 lbs on normal shop air. The Belleville stack is a large topic that is too frustrating to discuss on a forum

Are you sure a few hundred pounds is adequate for BT30?  Sounds low to me.  I know ISO30 requires on the order of 1300#, and I would've thought BT30 would be the same.  I think the issue is not so much torque capability, but loss of rigidity caused by un-seating of the taper, due to the holder being pulled down due to cutting forces, and leverage through the tool holder and tool holder to spindle interface.  I have seen the spec for ISO30, but not BT30.  I would not think the drive dogs would be of any real value until you get up into the 5-10 HP range.

BT30 has two specs. above and below a certain RPM. I would have to look it up again (old now,  memory not so good) but it is something like 625lbs for high RPM and somewhat less than that below a certain RPM threshold. BT30 is small and very high speed. If one compares the surface area of a BT30 taper with that of R8, things become clear. Currently I am running a 140V 37A DC brush servo motor for the spindle which I run at 180V.  Right now I only have 10A to feed it, but sitting on my desk is a new Copley model 180V 30A. That's more than 7HP.

I don't know anything about the ISO spec you mentioned, but most likely there are advantages and disadvantages to every spec and to every PDB and ATC arrangement. As a development engineer, I've had a life of setting out to build my 'perfect on paper' designs only to find as I go thru the build process all of the things I *should* have thought of  . . . . LOL!!

640

SmoothStepper USB / Re: smooth stepper and modbus I/O

« on: May 16, 2012, 06:43:28 PM »

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.