Hello Guest it is April 25, 2024, 01:23:59 PM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - stirling

1541
Hi Tweakie - don't know if this is any use to you but a while back I spent a bit of time looking at reducing the delay after switching outputs. http://www.machsupport.com/forum/index.php/topic,13206.msg86699.html#msg86699 (post #11)

Cheers

Ian

1542
General Mach Discussion / Re: Mch3 plasma THC min and max question
« on: June 28, 2010, 07:29:57 AM »
I mean the problem is that it allows
THC to go under the set minimum value, however it should not do this.

An interesting thing is that when emulating the THC (with keyboard keys) then it works well, it does not allow the Z to go under min. THC value,
but when the keys changed to LPT inputs then it works unwell.

Balazs - just double checked on my system and it works fine emulated AND for real.

Cheers

Ian

1543
General Mach Discussion / Re: stepper or drive problem
« on: June 28, 2010, 06:08:25 AM »
Just going back to your first para.

I had an incident yesterday where my X axis stepper lost it's "grip" so to speak. That is it lost its orientation by a number of steps and it wasn't "locked" when not in motion. The ball rod could be turned somewhat easily when the motor should have been holding it in place.

When a stepper is "holding" i.e. powered but not being rotated by the driver and IF you supply enough external torque, the holding torque will be overcome and the motor will then spin freely i.e. even more freely than an unconnected motor. It won't even have that light cogging you get from the permanent magnets. This is one of the few ways you CAN actually spin a stepper "smoothly" with virtually no resistance. The problem is that a stepper has it's maximum torque when stationary (hence why the holding torque is allways quoted) so IF you can "break" that relatively easilly it's all down hill from there I'm afraid. i.e. if the motor is already being driven correctly in terms of current, voltage etc. no matter what you do you will never get more torque than you had when it was stationary. If this is a new issue with your system I'd be tending to think hardware issue more than software - could be anything - but I'd look first at an overheated motor being temporarilly or permanently damaged.

Don't know if this'll help but just what I'd be thinking.

Ian

1544
General Mach Discussion / Re: Accurate homing
« on: June 28, 2010, 04:56:23 AM »
About jet fighters, unfortunately(?) it's not the language that make the program ! and a precise idea of what you want to do + a good knowledge of what can be done may compensate a n heavy syntax also our computers are very fast now so i think we can handle it.
I also meet guy who where programming in c VERY inefficiently !
And since some manage to do it so i can do it too(hopefully)
I stand corrected - sorry for my attempt at encouragement by way of a little joke...

1545
General Mach Discussion / Re: Mch3 plasma THC min and max question
« on: June 27, 2010, 07:58:31 AM »
You don't say which THC you're using but I use the THC300 and it's a bit of a black art to get it to behave and I find myself doing things just like you've done. That said any THC shouldn't command Mach to go lower than whatever you've set your cut height to be as long as you've got your reference voltage set correctly.

Re: your -ve THC min: Again you haven't said what screenset you're using but I'm guessing it's the "default" mach plasma set. If so then you're quite right it doesn't allow -ve numbers - no conspiracy - just cockup. You'll need to get the screen editor of your choice out and change the field to %+1.3f. (note the plus sign)

Cheers

Ian

1546
General Mach Discussion / Re: Accurate homing
« on: June 27, 2010, 07:13:54 AM »
Also take a look at the cypress VB manual in the wiki

i used to program in C
Then it's like you used to fly jet fighters and now you're about to learn how to flap your arms (but with one of them tied behind your back) - you'll be fine.

Cheers

Ian

1547
VB and the development of wizards / Re: Y, U, V Change X DRO
« on: June 26, 2010, 01:48:08 PM »
Not sure what an optimizer is in this context but wouldn't it be better to configure your optimizer for your machine? Seems a bit AB to me  :)

Cheers

Ian

1548
Let's see if we can't bust another myth for fun. realtime means real time.

The two types of realtime system that I know of are: Soft and hard. We're dealing here with soft.

To be called a soft realtime system two conditions have to be met.
1) The jitter must be kept within acceptable limits - but there will allways BE jitter. Remind you of anything?
2) The system must provide ready access for applications to be given higher priority than system functions if required.

No. 2 is really where RT linux passes and standard Windoze doesn't. AFAIK Art worked long and hard to get round that one - but get round it he did.

Another one.

Stepper motors can lose the occasional step.

Personally I've never seen it happen. I've seen steppers stall - period - but never have I seen one miss the occasional step. Not saying it absolutely CAN'T happen because never say never but here's why I find it difficult to understand how it can happen.

So our stepper is cruising along at whatever rpm and for some reason misses a step. The next pulse comes along and what? Well it's not going to move the stepper because the driver is in the wrong phase. Our stepper is still stalled. The next pulse comes along. No - still out of phase - our stepper stays where it is. In fact with a full step drive the stepper will miss 4 steps minimum because of incorrect phase and will allways lose steps in multiples of 4. (In a microstep system it will miss 4*microstep steps before the driver issues the correct phase signals). Anyway back to our full-step system - the 4th pulse comes along - good - correct phase, the motor moves a step from stationary. The 5th pulse comes along. Ooops - way to soon. The controller is sending out pulses at the speed the motor would have been going if it hadn't stalled, but it has only done one step from stationary - don't we need an acceleration ramp? The 6th, 7th, etc. steps are all too close together - stall....

The ONLY exception I can see to this is if the stepper motor is moving so slow in the first place that it doesn't NEED an acceleration ramp to get it going again. But wait - if it's going at that speed it's way up near the highest part of it's torque curve - so how come it missed a step in the first place? A system that misses steps at low speed is just plain not up to the job.

My ramblings for the day

Cheers

Ian


1549
Today I heard from someone else that EMC2 does have this function...
We have to be careful here and be clear exactly WHAT function we're talking about.

If you're saying that EMC can take encoder POSITIONAL feedback and correct a motor that's lost position then I'd say two things - "are you sure?" and "why?"

Let's take servos as an example as they allways have a feedback loop. It could be stated that servos are ALLWAYS in the wrong position and allways TRYING to get to the commanded position. The error between where they are and where they should be - the following error - has a maximum which is set to what is deemed acceptable. If this maximum is exceeded there's nothing ANY controller can do - it's too late - it's happened - the fat lady has sung!. If you're going to let ANY controller correct OUTSIDE the allowable following error - why not just increase what you regard as the acceptable maximum following error?

and that its the only cnc controller that does that because its working on linux and not windows..
May the great engineer in the sky save us from the Linux high priesthood. Linux is a great OS but  I wouldn't be surprised if one of the faithful claimed it could achieve world peace before dinner. EMC runs under a modified kernel just as Mach does. A vanilla Linux could not run EMC for exactly the same reason as a vanilla Windows couldn't run Mach. Neither of them are realtime systems and that's the challenge, to get them both to mimic one as best they can. The advantage the Linux guys had was they had access to the kernel source code. Somehow I don't think Bill and Art are that close!

The only thing I dont understand is... Why do Professional controls like Heidenhain, fanuc, siemens etc something similar like that?
Yes the do have servo's with encoders  connected to the drives but the frequently also have a measuring system like a liniair encoder (glass ruler) to give feedback to the controls . Thats a real closed loop..
Well someone who knows more about glass scales will hopefully step in. But I don't think that's what glass scales do. I thought their purpose was for accuracy. BUT AGAIN - If a drive can keep the servo within the following error limit - and they do - because if they didn't they'd be as much use as a chocolate fireguard - how can you improve on this?

All good fun...

Cheers

Ian

1550
Mach doesn't know or care whether you have a servo or a stepper system. It just sends out step and dir signals and trusts that whatever's attached does what it's meant to. The only difference is that with a servo drive you can connect the servo drive's fault output to Mach so that Mach get's to know about it. What does Mach do? It stops sending signals. Of course you can put encoders or whatever you like on a stepper. But you would have to get that "whatever" to detect a missing step and let mach know and Mach would do exactly the same thing - just stop sending signals. AFAIK there are no systems for steppers that will "re-position" after a lost step and to be honest if there was IMHO it would be pointless. In fact it would be as pointless as a servo system that tried to re-position after it had exceeded it's allowable following error. If you REALLY want the warm feeling of knowing that your system has lost position and that Mach will stop, then personally I'd go servos. Each motor brings there own advantages to the party but If it looks like a duck and quacks like a duck then it probably is a duck - no point in trying to pretend it's anything else.

Cheers

Ian