Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: stirling on May 07, 2010, 11:34:12 AM
-
I'm sure I've read this somewhere but can't find it. How often does Mach read input signals - I have in mind it's somewhere like 100Hz but I'm not sure. Specifically if it makes any difference - how often does Mach read THC UP/DOWN?
Cheers
Ian
-
10Hz update at the moment for Mach, Rev 4 will be faster.
Hood
-
Thanks Hood - Looks like I was being a bit optimistic with my 100Hz.
Cheers
Ian
-
Yep, just a bit ;D
I tested Rev4 at 100Hz and wow what a difference but there were issues so think it was dropped back to 50HZ but its been a while so not 100% sure on that.
Hood
-
hi, the signs of input for Home also is read each 100ms?. Then would have a error in zero machine, this is correct?
I think which the measurement should be done in less time, minor a 10ms.
regards
-
Not really sure I understand what you are saying but if the Home position is read at the same update rate every time then it should be accurate. Changing the axis homing speed from one home to another will however make for inaccuracies.
Hood
-
I'm probably a bit slow and everyone else already knows this but... Re: probing - this must mean that in order to probe at the best resolution your machine is capable of you MUST probe at less than 10 steps per second right?
Ian
-
Ian I have found IF you calibrate your probe to the known probing speed then that accounts for the latency of Mach.
The probe here repeats well inside of .001"
-
But what's the accuracy of your machine Terry?
-
Anyway - back to my original reason for asking the question. Mach will raise and lower the Z for THC according to the inputs THC UP/DOWN. BUT - as the rate of update of inputs - i.e. THC UP/DOWN is only 10Hz then (for example) Mach could still be raising Z for a 1/10th of a sec after the THC UP has actually gone inactive. Not ideal. Yet from another thread active at the moment concerning the monitoring of spindle rpm, it would appear that the index input is special - i.e. it MUST be updating faster than 10Hz otherwise it could only monitor a well slow spindle. This seems strange - if Mach can handle the index input at a "decent" frequency - why not THC UP/DOWN? - Just trying to understand the implications for my own THC design.
Cheers
Ian
-
I use the index for read the velocity of my motor spindle, have ten groove in the axis and the motor rotate until 3000rpm, then the input frecuency is of 500hz and this is read correct. In my case I would ask the foreros what precision obtained when using the HOME of the match?. I use the HOME with my drivers and the Z of the encoder and is precise.
regards
Renato
-
foreros is forum,,
-
HI Ian the mill itself repeats to .0001-4 depending on the time of day and the probe repeats to .0002-5.
Anything smaller than this I can't measure acurately here.
NOW ARE WE sure we are talkng about the port read frequency being only 10hz? I remeber Brian saying that the ports are read at about 2/3 of the kernal frequency.
How else would it be able to read RPM or encoders acurately.
NOW 10hz is the update rate for the VB/macro system and I thought Brains were faster than Macros.
I also remember testing the faster update rates 50hz and up (nice)
.
-
What I understand it to be, things like index for threading, probably Homing etc that are part of the driver are very fast, probably kernel speed, but other things like normal I/O are at Machs update speed which is 10Hz. Brains themselves are fast but Mach reading of them limits them to 10Hz.
But as said that is just my understanding and as I have never talked about it to Art or Brian so I am just guessing really.
When messing with Rev4 the first thing you notice is the speed of the DROs counting, much quicker and clearer. Kind of like the difference between a set of Mitutoyo digital callipers and cheap Chinese ones, they both end up at the same place but you can actually read the numbers on the Mits as you move it.
Hood
-
Hmmmm - I think we're maybe getting there. I'm beginning to suspect that MACH reads it's inputs much faster than 10Hz but that WE via VB or whatever can only access them at 10Hz or about - simply because that is the "activation" frequency of VB. Brains may be faster and perhaps plugins even faster but as I know nothing about either I can't comment. Certainly the index input MUST be read much faster, I suspect it's not alone not least because you can't just read 1 bit of a port - you get 8 bits min whether you make use of them or not. Clearly it makes sense that THC and probe inputs (and probably others) should be as fast as poss. Homing however probably doesn't actually need to be AS fast because it's a two stage process - fast followed by slow. The only crucial read is as it backs off the switch and this as we know is done sloooooowly - giving plenty of time for a read. Also as Hood has previously said I think - it's consistancy/repeatability that matters with home. Home is where home is and as long as it's the same each time - job done. Thanks for your input folks - I'm getting a better understanding now - I think!
Cheers
Ian
-
I'm probably a bit slow and everyone else already knows this but... Re: probing - this must mean that in order to probe at the best resolution your machine is capable of you MUST probe at less than 10 steps per second right?
Ian
Probing is a completely internal operation, and probe input is sampled at kernel speed. The 10Hz is the macro-pump rate, which has nothing to do with probing.
Regards,
Ray L.
-
I'm probably a bit slow and everyone else already knows this but... Re: probing - this must mean that in order to probe at the best resolution your machine is capable of you MUST probe at less than 10 steps per second right?
Ian
Probing is a completely internal operation, and probe input is sampled at kernel speed. The 10Hz is the macro-pump rate, which has nothing to do with probing.
Regards,
Ray L.
At this point in the thread maybe so Ray (see my last post above yours) but at the time I posed the question the thread wisdom was that ALL inputs were read at 10Hz.
That said...
Probing is a completely internal operation
generally yes - but not in a dynamic probing routine and then the 10Hz macro rate really bites you in the ar*e.
Cheers
Ian
-
I'm probably a bit slow and everyone else already knows this but... Re: probing - this must mean that in order to probe at the best resolution your machine is capable of you MUST probe at less than 10 steps per second right?
Ian
Probing is a completely internal operation, and probe input is sampled at kernel speed. The 10Hz is the macro-pump rate, which has nothing to do with probing.
Regards,
Ray L.
At this point in the thread maybe so Ray (see my last post above yours) but at the time I posed the question the thread wisdom was that ALL inputs were read at 10Hz.
That said...
Probing is a completely internal operation
generally yes - but not in a dynamic probing routine and then the 10Hz macro rate really bites you in the ar*e.
Cheers
Ian
Ian,
I don't know what you mean by "dynamic probing routine", but if you're using G31, it takes a step, then checks the PROBE input. The 10Hz rate has nothing to do with it. Were this not true, it would be absolultely impossible to probe at 50IPM, as I routinely do, and get 0.0001" repeatability. If you're directly monitoring the PROBE input with any kind of macro, then you ARE subject to the 10Hz rate.
Regards,
Ray L.
-
Ray
I'm not disputing anything you say. As I've already said, we established this earlier on in the thread. ;)
By dynamic probing routine I mean one that determines at run time what it's next step will be based on previous steps.
But riddle me this. Why doesn't Mach *appear* to work in the same way with regards it's THC UP/DOWN inputs i.e. take a step and then check THC UP/DOWN ?
Cheers
Ian
-
Ray
I'm not disputing anything you say. As I've already said, we established this earlier on in the thread. ;)
By dynamic probing routine I mean one that determines at run time what it's next step will be based on previous steps.
But riddle me this. Why doesn't Mach *appear* to work in the same way with regards it's THC UP/DOWN inputs i.e. take a step and then check THC UP/DOWN ?
Cheers
Ian
Because torch height isn't controlled by G31.... It's a completely different, and less accurate, control loop. ONLY G31 behaves as I described.
Regards,
Ray L.
-
Because torch height isn't controlled by G31....
??? At what point did I suggest it was?
It's a completely different, and less accurate, control loop. ONLY G31 behaves as I described.
That's what I'm trying to get at and obviously failing miserably... I'll try again as simply as I can...
If the G31 control loop tests the probe input at kernel speed then WHY does the THC control loop not test THC UP/DOWN inputs at kernel speed?
-
That's what I'm trying to get at and obviously failing miserably... I'll try again as simply as I can...
If the G31 control loop tests the probe input at kernel speed then WHY does the THC control loop not test THC UP/DOWN inputs at kernel speed?
Probably G31 is part of the driver code and THC is not.
Hood
-
You may well be right Hood. I guess the thing is that at first the view was that inputs were ALL polled at 10Hz. Then came the issue of the index input which we agreed must be much faster than 10Hz in order to work as it does. We then learned that it's fundamental to probing that it's input is read at kernel frequency. My contention is that IF THC was done at kernel frequency or at least a deal faster then it too would benefit greatly. I wonder why therefore, that the great and good chose to leave it slower. To be honest I'm not entirely sure this IS why THC is sluggish, which is where I was trying to go but somehow got distracted. I was just attempting to see if I could figure out why it's slow and if there was anything I could do to improve it's response.
Cheers
Ian
-
Next time I see Brian online I will ask just to make sure.
Hood
-
Got a message from Brian, THC is in the driver so should be fast. Not had a chance to actually chat with Brian but will try and get more details later although I am thinking it will really need to be Art as he is the guy that does the driver.
Hood
-
Thanks Hood - be interested in your findings.
Ian