Hello Guest it is May 22, 2024, 04:34:56 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 - gumbyrulesyou

Pages: 1 2 »
General Mach Discussion / MPG jog rate - Unresolved or not?
« on: August 26, 2015, 01:42:01 PM »
This issue was posted...maybe in 2008 I think? Was this ever addressed or resolved? The thread digressed in to trade show scheduling rather rapidly...

I just dusted off my mill after a couple of years, downloaded the latest MACH3 and started to test to make sure everything was OK.  I have an MPG pendent that I built which has two rotary switches. These go into a keyboard emulator (IPAC) then into KeyGrabber (utility software) to pass the appropriate keystrokes to MACH3.  I modified the 1024 standard screen set as follows:

Note:  I'm set to Imperial units

MPG X axis    <ALT X>    OEM Code 259
MPG Y axis    <ALT Y>    OEM Code 260
MPG Z axis    <ALT Z>    OEM Code 261
MPG OFF       <ALT T>    OEM Code 276 (Which I use to turn MPG on/off)

All of the above work, so the scheme is fine
Now the problem is with the rosolution:
.01           <ALT U>    OEM Code 267
.001          <ALT V>    OEM Code 268
.0001         <ALT W>    OEM Code 269

The above values were taken from the standard settings (or at least how I interpeted them) from MACH3 default configuration.

The MPG is calibrated to 4 clicks per detent

The problem:
Regardless of the setting I choose for the resolution, I seem to get about .0014" movement of an axis for each click of the MPG.  I also have a joystick set up and I get the same result from the joystick on step mode (actually, the joystick sometimes steps and sometime not, the MPG always steps.  When the joystick does step it's the same about .0014".

I have not been auditing the group for a while, so if this was addressed before, I appologize.

Any ideas about what's going on and how to fix the problem would be appreciated.



General Mach Discussion / Re: differential mpg
« on: August 26, 2015, 09:49:55 AM »
Hey Don,

That board from CNC4PC should probably do the trick. I used that same chip on a board I built years back for one of the CNC4PC MPGs that I needed a differential signal out of.

 I'd get rid of those modular jacks and solder the thing directly in place. RJ-45 gets used a LOT for encoders and it really shouldn't get used EVER. The twisted pair is great, but those jacks suck for machine tools, and the often solid CAT5 wire doesn't like constant flex.... Maybe not applicable in your setup. But I digress. Those boards should be great.

Good luck!

So I have an MPG going in to a USB Smoothstepper in Mach3, and everything is grand, more or less. Electrically, all functions are working - - MPG jogging, X/Y/Z/A/OFF select, and when I TAB out to the MPG mode window, selecting the .001 / .01 / .1 changes the 'Cycle Jog Step' number to what it's supposed to be, and the encoder isn't dropping steps or anything funny. It's a differential drive going in to Smoothstepper's special inputs and it's clean as a whistle.

Problem is..

Changing that scale dial does nothing to change the MPG resolution. I once had this working on an AJAX-CNC system and it worked pretty much as I thought it should, and I THINK I had it once working right on Smoothstepper, but right now, it's doing squat. Also, the step distance per tick seems to be rather arbitrary. My current count/unit is at 4, which is technically "right" for my MPG.

I have the MPG mode set to Step/Velocity. I can set it to MultiStep and it sort of works, but it shakes the crap out of the machine.

Now, I'd be happy to change the BRAIN associated with it to adjust the COUNTS/UNIT for the MPG in question, but I can't find a code for that.  I know this question has been floated around the forums before, but never really answered that well. Is there an OEM code to change this? There are codes to change the motor pulses per unit, this one seems like it should have a code too?

I'm running Mach 3.043.062 and USB Smoothstepper V17FD

I'm running Mach 062 on the recommendation of Warp9TD - http://www.warp9td.com/index.php/sw/software-mach#MachThree
Apparently it's more stable?

Anybody have any thoughts?



General Mach Discussion / Re: differential mpg
« on: August 25, 2015, 07:27:50 PM »
Hey Don,

There's no setup of a differential encoder - This is fully dependent on your hardware. If your pulse generator / smooth stepper / PoKeys / parallel port (hah!) doesn't have +A and -A (and +B and -B) inputs, there's no way to use your encoder...UNLESS!!! (unless) you use a differential line receiver chip, preferably dual - One channel for A, and one for B, or a quad if you have an index pulse you can't live without in which case you can use three of the four channels. Anyway, this $2 chip will convert the differential signal in to a single ended output that can go in to your little pulse generator of choice. This is OK, because you can use really short wires and the odds of the signal being corrupted are now small. That's the whole point of differential signaling - It's noise tolerant(ish)

On that note, single ended encoders are STUPID and have NO PLACE in a CNC machine. A car stereo? Fine. And sure, they use a few less wires and maybe cost a little less, but it's not enough to justify the risk of ruined parts or ruined digits and limbs.

Buy a $3 chip and make what you need, or spend $10 on one of these....


Good luck and happy chips!


So I'm wondering what other people's thoughts are on the dspMC/IP system. I currently have an Ajax / Centroid system in my CNC router, and I sort of regret putting it in there, mostly because it's badly supported, look-ahead and constant contouring don't seem to really work right, it's a horrible slow manual process to tune the PID loops, and forget using the auto-tune. In fact, I think I've been running my servos completely out of whack for 2 years now. You have to shut down mach AND the machine and restart the CNC and Mach just to TRY your PID settings. Totally convenient. Just like my Apple II/e. I know they're short handed there, but it's really just been a nightmare. They tell me to buy their Centroid software, but punching in all those unlock codes to even attempt to get autotune going in the Centroid software always ends in getting locked out .... Do I really want to give them another thousand bucks to have a system that still runs like crap? I'm  not really sure. The reason I sort of like the idea of the dspMC/IP is because it runs in MACH and in CNC Linux / EMC and probably some of DSps software too. Is it better supported? Can I do auto-tune ( I have 1KW AC servos with +/- 10V control) Is it stable? Does it have analog spindle control?  What about my MPG - Currently putting out differential quadrature, should work, right? My servos output differential quadrature too. Do I have to restart to try new PID settings? It homes to Index pulses, right? And the MPG connects to the unit directly, right?

What are people's thoughts? I currently have a machine that works and is making money, but isn't without it's fairly major problems, most of which I attribute to the Ajax/Centroid brain in the cabinet.

Works in progress / Re: Any screens that DON'T use bitmaps?!@!?
« on: March 02, 2010, 09:59:54 AM »
Man, I hope anybody that runs a CNC knows the difference between vector and raster. We've all experienced it when somebody asks to CNC cut a picture of their dog. Seriously all joking aside, the macropump vs VB macropump comment makes me wonder if the "best practices" are really known to all who customize Mach, and all these sleek screens that look like a science fiction movie do nothing except to impress your wife when she visits the shop. The reality of it is that there is ONE critical process, and that is the proper and timely production of pulses from the LPT port, and anything that jeopardizes that process, no matter how small the impact, must be looked at carefully and a determination should be made whether the additional load's benefit outweigh the risk of corrupting the pulse train and hence destroying a part.... hence my question about the text only screens. I know that I don't really dare to switch screens during a run...especially when I use a smooth stepper. If the part is even moderately complex and there's a graphic of the tool path, it will often conk out while redrawing. Never a good thing.

Works in progress / Re: Any screens that DON'T use bitmaps?!@!?
« on: March 01, 2010, 08:11:17 PM »
50% LESS sounds good. I think if I can find a spare nanosecond however, that I'll go ahead and make a text only screen. For something so CPU sensitive as Mach I'm a little surprised that this doesn't exist. Fear not.. I'm gonna make one, just as soon as I kill off a few of my clients.

Works in progress / Any screens that DON'T use bitmaps?!@!?
« on: February 25, 2010, 01:50:41 PM »
Are there ANY screens out there that don't use bitmaps? I know I'm free to make my own, and I'll do it, but I don't want to if they already exist.  I personally find that most of the screens out there are hard to read and are all go overboard with drop-shadow, emboss, gradients and silly fonts, etc, all of which has got to be sucking up RAM and CPU resources. Does such a thing exist?


Well I went in and screwed around with the script a bit, and tried probing with G91 - I don't know if this is a good idea, but at least the tool moves in the correct direction now, instead of trying to rapid in to the bed ..The script appears to call the current Z work coordinate in to account when it moves, and the setter height, and does some arithmetic before it records the tool length. The parameter it returns, '2002' is the Z height in work coordinates. I think there are 6 points that a G31 returns - 2000-2005, corresponding to X,Y,Z,A,B,C in current work coordinates. Where can I get values for the MACHINE coordinates??  Also, the tormach code is sorta commented, but lots of those OEMDROs need to be reverse looked up to find out what they are, and also in the tormach code, it comments the parameter 2002 as "z machine coosys" which it does NOT return data in the machine coordinate system, it's work coordinates. Frustrating, but maybe whoever wrote the code thought that it was machine coordinates and thats why it's screwy. Also, I'm using a smooth stepper - When I probe G31 while in machine coordinates, the machine probes with ALL THREE AXES moving, even though I might only specify one axis. Is this smooth stepper or Mach?

OK - I'm having a little trouble with these routines, particularly the "Destroy Probe" setting, which is activated by showing "machine coordinates" and attempting a "Set Tool Length" probe. Somehow, the behavior changes if the DRO is set either to machine or work coordinates. In machine mode, the tool goes down, touches the setter, pauses, then goes down another inch or so, ignoring the probe and smashing it....except in my case, because I was using a wooden dowel and had my hand on the E-stop.  Other times it probes UP. yes, UP. I touch the setter, it pauses, then does an upwards retract of 0.1 or whatever. Then there's a whole thing with the tool setter height, work offset, etc. Seems pretty complicated, which is where I see some numbers getting swapped around. I'm not going to go in to the button script and rip it up just yet, but for this project, I just want to keep the setter in one place, fixtured to the machine. As long as the offsets of the tools are all correct in respect to each other, and you load one tool and set it's length right, and zero it off the part, then for every other tool you load and probe, it shouldn't matter WHAT the sensor height is, or what the current work coordinate is.  I dunno. I don't get it, except that I don't trust the machine and the setter, and I don't really want to put the setter on the work, since, well then it's not fixed, and what if I set a zero to the material top then carve it all away. I know I should set it to the bottom, but sometimes it just makes sense.  I just need a tool setter routine that I can jog over to the setter position, change the tool, and press "GO" and it plops a number in to the tool table. After all, when I measure with a height gauge on a granite plate, I don't have any reference to the thickness of the TTS tool holder measuring block, or the workpiece zero or any of that, it's just a Z height offset for the tool, and as long as that number is 1.000 different for a tool that's 1" longer, that's all that matters.  Can somebody let me in on whatever secret there is?

Sorry... i'm just really frustrated right now.


Pages: 1 2 »