Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: revwarguy on January 31, 2010, 03:20:25 PM
-
Hello,
Does anyone know anything about a bug where probe signals are lost, perhaps while using a game controller as a pendant?
I have ruined two bits now.
I use a touch plate and the blue screen mods to single click a zero Z axis setting. I ALWAYS touch the plate to the bit to see the green "LED" come on. After having worked 99% of the time, on two occasions now, after testing the connection, the bit touched the touch plate, and kept on going. Luckily, I was near the estop, but it ruined the tip of the bit. The first time, I assumed it was my carelessness, but after the second time, I went in another direction and built a Z Zero setter, as shown at
www.liming.org/cnc on page 5,
based on the one shown on the cover of the recent Digital Machinist magazine.
Since then, on a thread in CNCZone, I learned that others have reported seeing lost probe signals while using Keygrabber. I do have a USB Logitech game controller hooked up, but I am using Logitech's key programmer, not keygrabber. Anyone know about any problems in this area with either keygrabber or Logitech's stuff?
-
Afraid I dont have an answer but I am wondering, does your probe sometimes move at a crawl and others at the correct speed?
Hood
-
I'm wondering (actually have been for a long time now) whether it's maybe time this issue received some attention. The forum is littered with similar reports of the probe not stopping on contact. I KNOW there are issues with issuing a G31 from VB which is why I moved my probing routines code into a dll where they were way more reliable. Even then though I've had probes not stopping in gcode based basic bed o nails and such.
Ian
-
I have never had this problem (yet!) - Z axis always stops on probe contact.
I use PCB material for the touch plate and obviously the copper surface has to be kept very clean or else the oxide film becomes an insulator and would cause problems.
Nice machine you have built revwarguy - please post some pics of things you make with it etc we would all be most interested to see them.
Tweakie.
-
I have has this happen twice. I dont use a game controller tho. I use a jog dial if thats usefull info?
I had thought it must have been something i did. I almost killed a $$$$ Omron switch.
-
Afraid I dont have an answer but I am wondering, does your probe sometimes move at a crawl and others at the correct speed?
Hood
Hood,
I have that problem. Do you have it with the SS, or PP? Mine, with SS, will do that on the first probe after start-up. I command a G31 at 5 IPM, but it instead moves about 0.0001"/second. After the first probe completes, it works correctly.
Regards,
Ray L.
-
Ray,
I don't have the problem, I knew you had it and was wondering if there was a possibility that it was USB related rather than SS specifically.
Hood
-
I don't know if my problem is related to the game controller or USB or not. When it only happens once in a while, any hypothesis is hard to test. I have:
Mach3 latest version, XP SP3, motherboard type parallel port, G540 as the BOB, and a Logitech game controller. I have seen the failure mode when using either Keygrabber or the latest version of the key aliasing software from Logitech. Networking and virus checkers are disabled while Mach3 is running.
I can't afford to keep losing bits, so I've gone to a different way to set the Z, the one shown on the cover of this months Digital Machinist. Is there some way to check on reported bugs and their status or place in the queue for fixing?
-
Not certain it is a bug as I have been running the auto tool zero for possibly 12 months now without issue and it has had plenty of use.
Greg has done a lot of work on this correcting possible problems that could occur, depending on the current Mach settings in force when the script is envoked and perhaps the best for me has been the addition of the G90 to this line Code "G90 G31 Z -15 F" &ProbeFeed 'Probing move at ProbeFeed rate.
Other related factors (which have been well discussed on the Zone) include residue on the tool shank or in the collet, partially insulating the tool from ground and also how good is the earth connection of the spindle shaft through its bearings ?.
There are, I think, so many variables to be considered before assuming it is a bug (setting the Zaxis scale factor to 2 and then using auto tool zero should spell disaster).
Tweakie.
-
Revwarguy, is the controller a wireless controller? Reason I ask is I've heard numerous issues using wireless devices.
I'm in the same boat as Tweakie, with a crude piece of circuit board connected as my probe. I was setup for the touchprobe for over a year (at least) and never ran into an issue. Then I heard about all the G31 issues and was thinking I was just living on borrowed time and ended up following Gregs direction and copied his updated macro into Mach. Knock on wood, still no issues with the touch probing using a Shuttle Pro 2.
Dave
-
Well, each time it happened I touched the plate to the bit to see the light come one, and then clicked the mouse to run it. I suppose it is possible that in the meantime the connection became poor, but I really believe that is unlikely. It worked for me many times as well, but it also ruined a couple of expensive bits. In any case, setting the Z axis in this manner is proven to be unreliable for me, so I am using a different method.
Not trying to point fingers, but I though Artsoft ought to know that there are problems occuring.
Also, it was a wired USB game controller, not wireless.
I am just using the mods I downloaded for the blue screen set unmodified - what is this G90 code - do I need to edit the script for setting the Z?
-
No worries on pointing fingers, there's obviously a problem as you're definitely not alone apparenty.
I was just trying to narrow down some issues, but if it's wired, I guess we're back to square one in the "investigation". There are just so many various manufacturers out there, it makes it difficult to find where the culprit is.
It now makes me a "little" nervous using this at times,
Dave
-
I would not depend on a current return path through the collet/toolholder, bearings, spindle housing, etc, etc. It will never be reliable unless it was specifically designed for the task. It takes bearings with conductive grease among other things to get it to work every time. The other potential issue is that your using the machine frame, which is likely (earth)grounded, for a DC current path; using an (earth)ground as a current conduction path is just asking for trouble from ground loops.
I clip one wire to the bit and one to the stock or touch plate and have never had it miss.
-
"Greg has done a lot of work on this correcting possible problems that could occur, depending on the current Mach settings in force when the script is envoked and perhaps the best for me has been the addition of the G90 to this line Code "G90 G31 Z -15 F" &ProbeFeed 'Probing move at ProbeFeed rate."
Is this line to be added or changed in the blue screen mods that I downloaded? I haven't made any changes to what I installed. What effect does the G90 code have in this instance?
"Other related factors (which have been well discussed on the Zone) include residue on the tool shank or in the collet, partially insulating the tool from ground and also how good is the earth connection of the spindle shaft through its bearings ?."
Don't think its a Mach setting issue, as it worked 99% of the time.
My spindle is double insulated from the frame; therefore I have a stiff battery clip that I apply to the collet. You can see it on the URL given in the first post. As I said, this is clipped and tested to see the green "LED" light come on on the screen, and once it does, the Z setter button is clicked, so while a poor connection might be possible, I believe its highly unlikely.
At any rate, this method of setting the Z has proven to be unreliable for me, so I've gone to a different method that is just as easy, but without risk. It also works with tips that are non conductive like pens, diamond point engravers, etc.
My game controller is a wired USB, not wireless.
-
Here is the downloaded script code I copied for my z axis set button. If anyone sees anything missing or a problem, please let me know.
Rem VBScript to probe in the z axis
If GetOemLed (825) <> 0 Then 'Check to see if the probe is already grounded or faulty
Code "(Z-Plate is grounded, check connection and try again)" 'this goes in the status bar if aplicable
Else
Code "G4 P1" 'Pause 1 seconds to give time to position probe plate
PlateOffset = GetUserDRO(1151) 'Get plate offset DRO
CurrentFeed = GetOemDRO(818) 'Get the current feedrate to return to later
Code "F4" 'slow down feedrate to 4 ipm
Rem Probe in the z direction
ZNew = GetDro(2) - 2 'probe move to current z - 2 inches
Code "G31Z" &ZNew
While IsMoving() 'wait for probe move to finish
Wend
ZNew = GetVar(2002) 'read the touch point
Code "G0 Z" &ZNew 'move back to hit point incase there was overshoot
While IsMoving ()
Wend
If PlateOffset <> 0 Then
Call SetDro (2, PlateOffset) 'set the Z axis DRO to plate thickness
Code "G4 P0.25" 'Pause for Dro to update.
ZNew = PlateOffset + .25
Code "G0 Z" &ZNew 'put the Z retract height you want here
Code "(Z axis is now zeroed)" 'puts this message in the status bar
End If
Code "F" &CurrentFeed 'Returns to prior feed rate
End If
-
Is this line to be added or changed in the blue screen mods that I downloaded? I haven't made any changes to what I installed. What effect does the G90 code have in this instance?
If your machine is operating in Incremental Distance Mode when the Auto Tool macro is evoked then it will not work correctly.
The macro was designed to operate in Absolute Distance Mode and for this reason Greg suggested adding the G90 'to be sure to be sure'.
Tweakie.
-
The line
Code "G4 P0.25" 'Pause for Dro to update.
is also better replaced with
while isMoving()
wend
For a discussion of why - see http://www.machsupport.com/forum/index.php/topic,12764.0.html (http://www.machsupport.com/forum/index.php/topic,12764.0.html) which although titled "G4 versus sleep" also deals with G4 versus while isMoving().
Cheers
Ian
-
Since the plate offset has never been zero, didn't the "while isMoving() ... wend: just get executed? If so, what difference could a G4 make - i.e., shouldn't the G4 just be deleted then?
Ahhh, the incremental/absolute thing - this has always bugged me. Why do g-code generators assume which mode it should be? Should that be declared specifically whenever it is used thereby avoiding any conflict? I will add the G90 to the G32 line, but I did check, and this is the mode that is the default upon launch.
-
Since the plate offset has never been zero, didn't the "while isMoving() ... wend: just get executed? If so, what difference could a G4 make - i.e., shouldn't the G4 just be deleted then?
Sorry I don't understand what you mean.
In the following code snippet:
If PlateOffset <> 0 Then
Call SetDro (2, PlateOffset) 'set the Z axis DRO to plate thickness
Code "G4 P0.25" 'Pause for Dro to update.
ZNew = PlateOffset + .25
Code "G0 Z" &ZNew 'put the Z retract height you want here
Code "(Z axis is now zeroed)" 'puts this message in the status bar
End If
The Z axis DRO MUST be allowed to finish updating before the Z axis is commanded to move by "G0 Z" & ZNew, otherwise the DRO and hence Mach's notion of Z WILL be wrong. The "G4 P0.25" does NOT guarantee this but a "while isMoving()" DOES.
Ian
-
I think I see what you mean, but don't understand why. If you include the previous two lines before your snippet:
While IsMoving ()
Wend
If PlateOffset <> 0 Then
Call SetDro (2, PlateOffset) 'set the Z axis DRO to plate thickness
Code "G4 P0.25" 'Pause for Dro to update.
ZNew = PlateOffset + .25
Code "G0 Z" &ZNew 'put the Z retract height you want here
Code "(Z axis is now zeroed)" 'puts this message in the status bar
End If
You see a While IsMoving () ... Wend just got executed, so the table is now stationary. Since PlateOffset is never zero, it falls through to the SetDro line, then the Code G4 P0.25. My mistake, since I didn't think the SetDRO command needed any latency, as it doesn't involve the actual table movement, it just sets an internal Mach variable such that it is complete before it returns to the next line. I take your word for it, but why do we need to wait for SetDro? What other commands that don't involve the physical table need to be waited on in these scripts?
Trying to learn,
-
I think Ray has already summed up the situation but this is my interpretation of the chain of events……
There are basically two programs running here at the same time and the speed at which they each execute is not always the same. Mach has many tasks to execute at the same time (screen refresh, keyboard poll, port monitor, etc. etc.) whilst being asked to update a DRO and will be considerably slower to respond or complete the task than the auto tool zero macro. Therefore it is possible for a macro to write a new value to a DRO and then read from this DRO the old value because Mach has not had time to update it fully. The ‘while / wend’ controls the speed at which the macro executes and has little, if any, effect on the speed at which Mach executes whereas the ‘G4’ dwell controls the speed at which Mach executes but has little, if any, effect on the speed at which the macro executes.
Tweakie.
-
This is why I provided the link in my earlier post. It's all discussed and explained there. I'll reproduce a little here. Tweakie is on the right lines but in detail: while isMoving() wend actually causes the VB thread to WAIT for the mach thread to SIGNAL the VB thread that it has finished doing the last thing it was asked by VB to do.
As I said in the linked thread, isMoving() would have perhaps been better named MachIsBusy() as it actually has nothing to do with whether anything is actually moving.
without this synchronisation of the two asynchronous threads (Mach and VB) the DRO could be read by the VB before Mach has actually updated it.
Any VB "command" to Mach should be seen as a REQUEST: as in "can you do this as soon as possible?" - NOT a COMMAND as in "do it now". Any VB that continues without waiting for Mach to say "OK - I've done it" is unreliable.
Ian
-
Thanks to both of you for your patience, I think I have a better understanding. I guess you just have to be very careful when writing VB scripts. I did look at the earlier reference to your thread, Ian, but I guess I gave up too soon, sorry - my bad. I will make the recommended changes.
It sure makes me wonder how many other sync problems are lurking.
Too bad there isn't a way to keep a single place for updated/corrected scripts and other add-ons, so that folks don't download the same troubles over and over. At least, if there is, I wish it were more obvious!
Thanks again for your help.
-
The UI in Mach is only updated periodically - roughly 10X/second. When you "write" a DRO, the DRO itself does not get updated immediately. Instead, the request to write the DRO goes into a queue of things to do on the next UI update. So, if you write a DRO, then immediately read it back, you stand a good chance of reading the old value, rather than the new one. Putting a Sleep(200) between the write and read should also guarantee a UI update has occurred.
All of this will me MUCH simpler and more deterministic in v4, and scripts will very rarely need to include explicit delays to get the expected behavior.
Regards,
Ray L.
-
Putting a Sleep(200) between the write and read should also guarantee a UI update has occurred.
This is misleading, and doesn't GUARANTEE anything. isMoving() tests a semaphore and while isMoving() wend repeatedly tests the semaphore. It is only when Mach sets this semaphore and VB reads that fact that it is "safe" to continue. A sleep(X) on its own is at best a "guess" and within the while isMoving() wend loop only serves to takes a little load off the CPU. The ONLY way to GUARANTEE synchronisation of asynchronous threads is via semaphores and the only way of reading this particular semaphore is via isMoving().
Cheers
Ian
-
Other than potentially unnecessary delays in the scripts, do you know of any other impact V4 will have on scripts or addons?
Also, any idea about the target date for when v4 will be available?
-
Putting a Sleep(200) between the write and read should also guarantee a UI update has occurred.
This is misleading, and doesn't GUARANTEE anything. isMoving() tests a semaphore and while isMoving() wend repeatedly tests the semaphore. It is only when Mach sets this semaphore and VB reads that fact that it is "safe" to continue. A sleep(X) on its own is at best a "guess" and within the while isMoving() wend loop only serves to takes a little load off the CPU. The ONLY way to GUARANTEE synchronisation of asynchronous threads is via semaphores and the only way of reading this particular semaphore is via isMoving().
Cheers
Ian
Ian,
Could well be you know something I don't, but neither Art nor Brian has ever indicated to me that IsMoving() is a *guarantee* of a UI update. In fact, on occasion, Brian has suggested using a delay. Certainly, if the machine is idle, a delay of 2X the update rate *should* guarantee an update has occurred, as UI updates are regular, timed events, unless the machine is too busy running a program. But, as I said, v4 will be FAR better in this respect. It is a little ridiculous for user to have to worry about this kind of stuff.
Regards,
Ray L.
-
Other than potentially unnecessary delays in the scripts, do you know of any other impact V4 will have on scripts or addons?
Also, any idea about the target date for when v4 will be available?
v4 scripts will be almost completely different - almost nothing will carry over, unless you run in "legacy mode", in which case you will not get any of the benefits of all the v4 changes. The v4 scripting environment will be a HUGE improvement over v3 - simpler, more consistent and predictable, but with greatly expanded functionality. It will be much easier to learn, MUCH easier to use, and capable of doing many things v3 simply can't.
Regards,
Ray L.
-
delete
-
Could well be you know something I don't, but neither Art nor Brian has ever indicated to me that IsMoving() is a *guarantee* of a UI update. In fact, on occasion, Brian has suggested using a delay. Certainly, if the machine is idle, a delay of 2X the update rate *should* guarantee an update has occurred, as UI updates are regular, timed events, unless the machine is too busy running a program. But, as I said, v4 will be FAR better in this respect. It is a little ridiculous for user to have to worry about this kind of stuff.
Ray
I wouldn't presume to think such a thing and I'd absolutely agree with what you say Art & Brian have said and I don't think I've said anything to the contrary. In an ideal world of course it would be nice if the semaphore was accompanied by the called thread's success or error status but we can't have everything.
I think you'd agree that mult-threading is not unique to Mach and I've based what I've said on the assumption that Mach implements it in much the same way as any other multi-threading application - if not then I'd be intrigued to know how and why.
Certainly if a called thread is expected to complete after a particular time, then a wait by the calling thread for some period longer than that *should* give expected results. But when a semaphore is available, I would suggest that it is better practice to use it.
The only reason I can think of where a wait might be preferable, would be if there were some concern over the reliability of the code implementing the semaphore. Not that I'm suggesting this is the case with Mach of course.
Cheers
Ian
-
Could well be you know something I don't, but neither Art nor Brian has ever indicated to me that IsMoving() is a *guarantee* of a UI update. In fact, on occasion, Brian has suggested using a delay. Certainly, if the machine is idle, a delay of 2X the update rate *should* guarantee an update has occurred, as UI updates are regular, timed events, unless the machine is too busy running a program. But, as I said, v4 will be FAR better in this respect. It is a little ridiculous for user to have to worry about this kind of stuff.
Ray
I wouldn't presume to think such a thing and I'd absolutely agree with what you say Art & Brian have said and I don't think I've said anything to the contrary. In an ideal world of course it would be nice if the semaphore was accompanied by the called thread's success or error status but we can't have everything.
I think you'd agree that mult-threading is not unique to Mach and I've based what I've said on the assumption that Mach implements it in much the same way as any other multi-threading application - if not then I'd be intrigued to know how and why.
Certainly if a called thread is expected to complete after a particular time, then a wait by the calling thread for some period longer than that *should* give expected results. But when a semaphore is available, I would suggest that it is better practice to use it.
The only reason I can think of where a wait might be preferable, would be if there were some concern over the reliability of the code implementing the semaphore. Not that I'm suggesting this is the case with Mach of course.
Cheers
Ian
Ian,
I agree 100% about the use of semaphores. But, one thing I've learned about Mach3 is that many features are not implemented anywhere near the way they "should" be. Many are basically "hacks" that sorta-kinda work most of the time. I've come across some real doozies where I can only scratch my head in disbelief. This is why v4 is taking so long - Brian is working very hard to get that kind of stuff out, and the deeper he digs, the more he finds that just needs to be ripped out and re-done from the ground up. He's already completely re-architected many whole major sections of Mach3. v4 will be MUCH better in all respects.
Regards,
Ray L.
-
Ray
Understood. I'll add myself to the list of those keenly awaiting V4.
Cheers
Ian
-
Is this better? From the Mach 3 wiki:
A frequent requirement is to have to wait for Mach3 when doing several commands, to keep them executing in order. The:
While IsMoving
Wend
Loop is the typical way of doing this.
ex:
code "G0X100"
While IsMoving()
Wend
However, this causes the system to make millions of calls to the subsystem to determine if Mach3 is finished. The CPU load rises terribly. A solution is to wait for 100ms or so each time you check unless you need a very tight response time. The solution is to use a syntax as follows..
Declare Sub Sleep Lib "Kernel32" (ByVal dwMilliseconds As Long)
.
.
.
Code "G0X100"
While ismoving()
Sleep 100
Wend
I suppose its somewhat moot, since this will go away in V4.
-
Is this better? From the Mach 3 wiki:
A frequent requirement is to have to wait for Mach3 when doing several commands, to keep them executing in order. The:
While IsMoving
Wend
Loop is the typical way of doing this.
ex:
code "G0X100"
While IsMoving()
Wend
However, this causes the system to make millions of calls to the subsystem to determine if Mach3 is finished. The CPU load rises terribly. A solution is to wait for 100ms or so each time you check unless you need a very tight response time. The solution is to use a syntax as follows..
Declare Sub Sleep Lib "Kernel32" (ByVal dwMilliseconds As Long)
.
.
.
Code "G0X100"
While ismoving()
Sleep 100
Wend
I suppose its somewhat moot, since this will go away in V4.
You are correct - you should *never* use:
While IsMoving()
Wend
Rather *always*
While IsMoving()
Sleep(10)
Wend
The length of the Sleep is not important, but having a Sleep in there is important, to avoid wasting many, many CPU cycles.
Regards,
Ray L.
-
but I think I'm right in saying you don't need the "Declare Sub Sleep Lib "Kernel32" (ByVal dwMilliseconds As Long)" as it's "implicitly" declared for you already.
Cheers
Ian
-
Sure... I think the wiki writer just meant to show the syntax of Declare Sub Sleep Lib "Kernel32" (ByVal dwMilliseconds As Long) there, and did not intend for that to be part of the code snippet in the example.
That was the way I took it, at least. :)