Messages

41

VB and the development of wizards / Re: DRO Skin variations

« on: September 13, 2011, 08:06:27 PM »

I'm not aware of any way to do either of these. If you find a way be sure to let us know!


Thanks,
Chris

42

Works in progress / Re: New IPS (Interactive Programming System) Professional Screen for Turn

« on: September 10, 2011, 06:48:07 PM »

I can confirm it does work, but I'm not sure how to call it from G-Code. Inputting 253 into the tool number DRO applies the offsets though.

43

Works in progress / Re: New IPS (Interactive Programming System) Professional Screen for Turn

« on: September 06, 2011, 07:49:03 AM »

I would be very interested in this screenset for our plastic shop. Our lathe runs basically all day long every day. I would be more than willing to put it through it's paces! We turn everything from very simple parts to fairly complex parts, and this looks like it would be very useful to us.

If not, then hurry up and release it!!! Lol... But really, it looks awesome!

Thanks,
Chris

44

VB and the development of wizards / Re: Using G-code files in Button Scripts

« on: September 05, 2011, 05:46:31 PM »

You can take a look at some of the wizards for good examples as well. They're all scripted, and many use teach files.

45

General Mach Discussion / Re: Height Control for Router Table

« on: August 18, 2011, 07:42:10 AM »

In a THC application it is fairly straight forward.  In your application, you'll be controlling the Z axis drive with the PLC, which means you'll need to send the Z step and direction pulses from Mach to the PLC, modify them and send them out to the drive.  Keeping the PLC and Mach in sync might prove to be a challenge.

You keep talking about a THC, but that's not really what you're doing.

Sending just the Z step/dir pulses through the PLC is definitely not enough. All signals must be kept in sync, therefore all signals must be routed through the PLC to impose equal delays.

I refer to THC only because it's the closest thing I've seen to my application.

OK something to think about (;-)  IF it was as easy to do "WELL" as buying a simple PLC do you think the only LOW COST solutions on the market today would cost $500

I didn't say it would be "easy", just not too difficult. It's all programming. The cost of the controller isn't the problem. Isn't it true that this job can be handled quite handily with PLC? I don't see anything here that would be beyond the capabilities of a PLC. Perhaps they have other motivations for custom electronics, such as protecting their product from being easily copied? After all, with PLC all you're really selling is a controller that can be obtained from anywhere, and some software. It would likely be harder to sell for maximum price than an integrated solution.

Maybe I'm going a little overboard with wanting full control of the height control process, but I don't see any reason not to use PLC, and I love the idea of having full control of the machine at both levels... It should allow me to use Mach3 the same as always, with full 3D capability as well as height control. Maybe someone can point out something that I'm missing.

Thanks again,
Chris

46

General Mach Discussion / Re: Height Control for Router Table

« on: August 16, 2011, 11:43:15 PM »

Thanks for the responses, it has been incredibly helpful. It seems the only sure-fire way of making a robust dynamic height control would be to send the pulses into a PLC and apply the THC there, delaying all signals equally. A PID loop could also be implemented in the PLC, and wouldn't be too difficult. The result would be a kick-a$$ dynamic height controller.

To me, it looks like there are too many barriers in Mach3 for this application (i.e. no velocity/acceleration control for THC, macros way, way too slow, applying offset directly to motor causes lost position, 1:1 buffer results in buffer under-runs, etc...). While I think it's likely possible, it doesn't look simple at all, while the PLC approach is straight forward and extremely robust.

Thanks,
Chris

47

General Mach Discussion / Re: Height Control for Router Table

« on: August 14, 2011, 11:18:37 AM »

I have no experience with THC at all, just trying to piece the information from the two of you together. The possibility does exist that the unit has PID and Mach3 can't utilize it. I'm not saying that is or isn't so, I have no idea. I don't run torch or plasma and am trying to learn if it would be applicable in my application.

Could you recommend such a unit for me to research?

Thanks, Chris

48

General Mach Discussion / Re: Height Control for Router Table

« on: August 14, 2011, 09:24:20 AM »

To clarify for others reading this, signal conditioning and PID are quite different things. Signal conditioning removes noise and/or modifies the signal to be accepted by the next stage. PID stands for Proportional, Integral, Derivative and is used to improve the accuracy of the error correction by speeding up or slowing down the corrections to make it match the actual error as closely as possible with minimal overshoot. Without it the error correction cannot be accurate, as overshoot will always occur to some degree. The PID controls both the velocity and acceleration of the correction. According to what's been posted here this is impossible with the standard THC controls in Mach3 as there are no provision for controlling the feedrate, and thus no control of velocity or acceleration, aside from using a fast feedrate and sending the signals as pulses. This is likely to cause choppy movement on Z.

49

Mach Screens / Re: VB code for jogging...

« on: August 14, 2011, 08:23:04 AM »

If you press "TAB" it should bring out the MPG flyout. Try using those buttons for jogging. Do they work properly? If not there may be a problem in your settings somewhere.... Let us know...

Chris

50

General Mach Discussion / Re: Height Control for Router Table

« on: August 13, 2011, 07:53:55 PM »

Thank you for the lesson rrc1962 and br549, it has been extremely enlightening, and thanks for the quick responses... I now see why this has never been done before.

It should be possible to alter the buffer in Mach3 via plugin dll, right? Timing would be a huge issue though, and it's probably impossible as the buffer will be emptying and being filled very very quickly. Hmmmm..... just thinking out loud...

It appears near impossible at this point due to the buffer delay. If you designed a board or used PLC to intercept the pulses to modify them "on-the-fly" you would have to delay all motor pulses by the same delay as is introduced by adjusting Z to keep all motions in sync.

Interesting.... Now I see why BR549 was suggesting PLC....

Chris