Hello Guest it is April 29, 2024, 01:40:37 AM

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 - HimyKabibble

701
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.

702
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.

703
General Mach Discussion / Re: Prox Switches
« on: February 07, 2010, 12:07:11 PM »
With this type of sensor you cannot wire it directly to your BOB.
The easiest solution would, I think, be to operate the device at 12 Volts and connect the output (black) wire to a 12 Volt relay coil with the other side of the coil connecting to ground (blue) then, just in case there isn't one already fitted within the sensor, connect a diode across these relay coil connections (polarity + to black / - to blue). You can then use the relay contacts N.O. or N.C. (as you choose) to connect to your BOB and ground.

Tweakie.

Why would he not be able to just use series current-limiting resistors and clamping diodes to the +5V on the BOB, or just a resistor divider?  Relays seem like overkill.

Regards,
Ray L.

704
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.

705
General Mach Discussion / Re: Negatating variables in G-code.
« on: January 30, 2010, 06:22:16 PM »
Wow, there's a G code standard that states that expressiions like #1 = [-#2] aren't legal?

I've reported that as bug in Mach several times over the past couple of years and I thought it just never made it high enough up on the priority to get fixed, I didn't know there was actually a spec somewhere saying it shouldn't be legal.

Having to do #1=[0 - #2] sure makes macros look ugly, I'd be really surprised of most of the modern CNC controllers (Fanuc, Haas, Fadal, Siemens, etc.) still adhered to that part of the spec.

Paul T.

G-code is largely defined by the NIST RS-274D standard:  http://www.isd.mel.nist.gov/documents/kramer/RS274NGC_3.pdf

Keep in mind, G-code was defined in the 60s, when computing power was *extremely* limited, which is why it's so simple, and, in some cases, seemingly brain-dead.  However, while most G-code interpreters are based on the spec, almost all have taken liberties with the definition in some areas as well, so there really is no "standard".  Fanuc seems to be about the most common variant.

Regards,
Ray L.

706
General Mach Discussion / Re: Saving Tool Table...
« on: January 30, 2010, 04:31:10 PM »
Tried pressing apply? works for me on the lathe.
Hood

Hood,

The tool table is loaded by my tool length probing macros, and that all works fine.  But the table apparently exists only in memory.  Is it really necessary to manually open the tool table the click "Apply" to get it written to disk?  If I manually edit the table, and don't click "Apply", exiting the dialog, and re-opening it will show the old settings.  But in this case, I probe all the tools, open the tool table dialog, and it shows the correct values.  Seems really odd that it would still be necessary to click Apply at this point.

Regards,
Ray L.

707
General Mach Discussion / Saving Tool Table...
« on: January 30, 2010, 03:30:46 PM »
What is the trick to getting Mach3 to SAVE the tool table when you exit?  My probing macros correctly setup the length offsets, but when I close Mach3, and re-start it, the offsets are all gone.  Surely there is a way to save the offsets to XML??

Regards,
Ray L.

708
General Mach Discussion / Re: Advanced Spindle Control
« on: January 29, 2010, 07:19:26 PM »
I believe this is what you need:  http://pico-systems.com/spindac.html

Regards,
Ray L.

709
Very cool axis brake.

Let me just make sure I understand:

You've got a disc brake off a motorcycle or somewhere. 

Instead of operating it via brake fluid, you've threaded a rod into the caliper that directly acts on the puck when your air cylinder rotates it?

Cheers,

BW

Bob,

The disc brake is off a bicycle, or mini-bike.  They are typically cable-operated.  This is a GREAT application for those!  I've considered putting a spindle brake on my mill, and one of those woudl be just the ticket.

Regards,
Ray L.

710
General Mach Discussion / Re: A Really Exceptional Vendor....
« on: January 26, 2010, 12:31:25 PM »
Heh, of course I did.  I found one that had very similar error codes and numbers from HSD.  HSD insisted it was wrong and the one sent from SIRCO was right.  At that point I vowed to never buy anything from them again and preach the gospel of the good vendors I did have.

I must say one of the exceptional ones was Home Shop CNC.  He met me on a Saturday to correct a milling problem I had.  I didn't expect that kind of service.

Barry



I'll second that.  Rick LaLonde is definitely one of the good guys.  I've been buying from him for years, and never been disappointed.

Regards,
Ray L.