Topics

1

General Mach Discussion / Machine goes wild with uncontrolled jog

« on: July 29, 2015, 06:57:19 PM »

I noticed several times that Mach3 (with an Ethernet SmoothStepper) went crazy and kept jogging after hitting an arrow until the machine hit a limit. 

Upon testing, I realized this is coming from holding the shift for Rapid, then releasing the shift BEFORE releasing the arrow.  After releasing shift THEN arrow, the machine keeps doing a rapid without any input.

Was this an intended feature?  If so, how do I disable it?

If it's a bug, how do I fix it?  It's super-dangerous, IMHO.

2

General Mach Discussion / Homing failed

« on: April 05, 2015, 06:40:53 AM »

I got some inductive prox sensors hooked up and they light up nicely on the Diagnostic page when you hold metal over 'em.

So I hit the Ref Y and all that it did was twitch once and the axis turns green.  It's nowhere near the home.

I thought maybe I screwed up the level, changed to Active-High, and then it said "homing switch already active, fix this and try again".  OK so no it was right before, and I put it back.

Now before this, I had the pin set to the wrong port, and of course the Ref Y operation just drove past the homing switch and banged into the mechanical stops.  But that tells me Mach3 DOES know how to drive the axis.

Noise is on the list of suspects, but I didn't see the M2 Home light blink on the Diagnostics page when moving the axis.  Also it just twitched the motor once and stopped.  It didn't do the run-into-the-homing, back-off, reapproach-slowly-and-stop.


Any ideas?

3

General Mach Discussion / Auto-aligning gantry during homing.

« on: March 08, 2015, 03:18:06 PM »

I have a wide gantry.  As is, when first powered up, the 2 rack & pinions won't be perfectly aligned.  That makes cutting a large square a slight parallelogram.  Both motors are "linked" inside Mach3 to step together, not in the hardware.

I do have precision-placed endstops.  Right now I just jog against them slowly until one motor stalls against the stop and allows the other to catch up and also strike and stall against the endstop.  The grinding sound of a stalling stepped attracts a lot of attention... "no guys, it's supposed to do that."

OK so I need homing switches on both sides.  Is there a method inside Mach3 (or someone's Plugin) to home by driving until one motor or the other hits the home, stopping that specific motor, unlinking the drives, and driving the other motor (whichever one it may be) forward until it, too, hits the homing switch?

4

Mach SDK plugin questions and answers. / Is there a Hitachi X200 plugin?

« on: February 22, 2015, 03:19:52 AM »

It's a common VFD, but I can't find one.  I made a "Brain" but it's not all that reliable, if the VFD's not running it can't tell.

I saw the Huangyang VFD has a plugin available, but all I could find was the compiled version.  Is there source code around to modify into an X200 plugin?

5

General Mach Discussion / Safer connection from Mach3 to X200 VFD?

« on: February 15, 2015, 04:43:04 PM »

I hooked up my X200 VFD (older blue one, not the new black one) into an RS485 link alongside the Ethernet Smoothstepper and built a basic Brain for it.  Speed and RPM control are ok.  RPM control is through the command bus, not PWM.

Problems I noted:

1.  The spindle RPM cannot be displayed on Mach3's RPM field.  I was told this was impossible to do because Mach3, for whatever reason, didn't allow the RPM field to be written via Brains.  Is that correct?  I tried using a Brain to write a constant number to it and no, it can't be written.

2. Mach3 cannot detect that the spindle is actually running.  Or, for that matter, that the VFD even has its breaker on.  It needs feedback for RPM and/or VFD errors I guess and throw an E-stop if it's not there.  But my first note is that is it not always an error for the VFD RPM to be 0 when the Target RPM is 10,000 RPM, because that's normal for the very first moments after the Target RPM is set.  
It also needs to stop trying to send the RS485 RPM command, because if the VFD's breaker is off and Mach3's console has the Spindle left "on"  because of operator error, I'd rather the spindle not spin up on its own when I reset the VFD's breaker.  If it threw itself into E-stop automatically when it didn't get spindle RPM, that problem should have resolved itself with an E-Stop.

3.  My greatest concern here- say Mach3 crashes.  Or the Ethernet cable to the Smoothstepper pulls out.  Or the 120v breaker pops (the VFD is on a different 208v 3ph breaker).  I don't expect the VFD to shut down, it will continue running since it was last given the RPM command and doesn't require ongoing commands to stay running.  How can I institute a hardware failsafe for this?  I have an Ethernet Smoothstepper here.  VFD control is all through the RS485 control bus on a separate link from the PC, I don't want to do with PWM throttle control for it.

4.  I did see a case where hitting Feed Hold stopped the spindle and when Resuming, it failed to restart the spindle.  Why would that happen?  Like I say, it restarted the spindle elsewhere immediately upon powering up the VFD breaker, so it's continuously sending the RS485 RPM command to the VFD.  IIRC in that case I hit Spindle Reset manually to adjust the work, but Mach3 didn't realize the spindle should be "on" again to resume, which is dangerous.

6

General Mach Discussion / Motion from XHC shuttle mpg pendant

« on: February 10, 2015, 02:15:33 PM »

I have a wireless XHC mpg:

http://www.ebay.com/itm/Wireless-Mach3-MPG-Pendant-Handwheel-for-CNC-Mac-Mach-3-4-axis-Wholesale-Price-/140918851970?pt=LH_DefaultDomain_0&hash=item20cf6b0982

It's pretty much a godsend on my 4x8 router.  The terminal's too far away to mess with the keys.  I guess a wireless keyboard would be nice too, but this fits in the hand.  And it's cheap, and has a DRO on the pendant.

What I'm bummed about is the handwheel motion.  It's a single speed, which means it's really not different than pressing a button.  That is, there's a"fast" setting where it moves in about 1/2" increments at a constant speed.  There's also a "slow" setting which moves in small incremental steps, like 0.02".  However, spinning the handwheel faster in either mode doesn't actually move the axis faster.  Rather, it just stays in motion at the same speed for as long as you're turning the handwheel. So it's not acting like a handwheel, it's not a handwheel if the speed you turn it has no effect.  Also that means it "loses" steps when turned quickly, so rotating 3 turns clockwise quickly and then 3x counterclockwise slowly will not return the axis to the same position even though the handwheel is in the same position, so there's no direct relationship between handwheel position and axis position.

I was wondering if there's any way to change that?  The XHC documentation's real limited here.

What I want is for it to
1) go slowly if the handwheel's turning slowly
2) go quickly if the handwheel's spun quickly and
3) make a consistent relationship between the handwheel position and axis position.  

Number 3) there, that does have a danger, that if you spin it faster than the axis moves, it'll cache the motion and may take some time to catch up so it will stay in motion after the handwheel is stopped, in order to get to that position.  

I guess that also means I'd want:

4) be able to change back the target on-the-fly.  That is, say the axis is slow and you've spun the wheel clockwise so it's been commanded to move 10" further than it actually has gone at this moment.  But you decide that's too far and turn the handwheel back CCW 2".  It need to go 8" and stop, not cache the moves where it goes to 10" and back to 8".

And I know that one seems difficult.  If I'm using the MDI and enter "G0 X10" and then enter "G0 X8", it can't possibly modify the X10 move and stop at X8.

7

General Mach Discussion / Maximum processing speed?

« on: February 10, 2015, 05:55:05 AM »

I am doing some raster 3D carving, and noting that the speed seems limited in ways that can't be explained by the actual machine.

I have a 6"x6" relief with a 1/16" ballnose doing 20% stepover.  So 2880 linear inches.  Feedrate 400ipm.   By itself, 2880/400= 7.2 min.  Which, I  understand, decelerating to a stop to lift up over a feature with an abrupt change in Z-height takes extra time.  And I watched it, on flat areas it rips right across but really slows to a crawl across detail with Z-movement.

The machine's XY axes were set at 600 ipm 40 in/sec/sec accel, z set at 200/50.  This got 37:30 runtime.  So I play with possible more aggressive numbers for acceleration and get only modest gains.  

For information purposes I went in and entered the max acceleration Mach3 allowed, which was 187.  Well it lowered the runtime some, to 22:44.    Tried kicking Z up to 400 ipm and still no improvement.  Kicked XY down to 400 ipm max, which opened up acceleration to be set to 281 in/sec/sec.  Still no significant change in runtime.  

Well if acceleration was the limiting factor, those crazy high acceleration numbers should have brought it close to 7.2 min.  But no dice.
 
Had a theory "maybe the Ethernet Smoothstepper has a processing limit" so I changed to a profile with Parallel Port.  No difference. 

Loaded Mach3 on a different PC just in case somehow it was looking at processor speed and slowing down the run if the PC couldn't calculate that fast.  No difference.

Changed Kernel Speed and restarted.  No difference.

Doubled the ipm in the file, no effect. 

So it seems like motor performance is not the reason time cannot be brought below 22:44.  Mach3 is introducing some sort of speed limit across detail that has nothing to do with acceleration- what is it??

8

Brains Development / DRO number for brain to control RPM?

« on: August 24, 2014, 05:36:01 AM »

I have a Hitachi X200 VFD controlled via modbus.  I can start/stop, change direction, and set RPM just fine.  S2000 = 2000 RPM on my laser tachometer.

I noticed the RPM DRO was reading oddly... something like "364" when stopped, "1736" when running at 2K.  I don't know where it was getting that number, it's junk.  Might be noise off a tach input with nothing hooked up to it.

So I went to make a Brain to read the RPM back off the Modbus.  But I'm not clear what the RPM DRO is.  I tried "True Spindle RPM" and it didn't change anything.  I took the Brain and change the Function to "f(out)=1234" so it should read a flixed 1234 regardless of whether the spindle's on at all or what its rpm target was set to.  I tried everything which sounded remotely like the name of an RPM DRO but no luck.
 
Is "True Spindle RPM" the correct DRO?  Do I need to go under General Config or Ports And Pins to change the input for the RPM readout?

9

SmoothStepper USB / ESS stuck in Reset

« on: August 17, 2014, 06:06:06 PM »

Have an Ethernet SmoothStepper Rev 1 on latest version of Mach3 with latest plugin, hooked up to a G540 driving a large CNC router with NEMA23 motors.  The E-Stop switch is routed into a G540 input.

If the E-Stop is hit, the ESS is stuck in "Stopped".  In fact exiting Mach3 won't clear it either, the power has to be cycled on the controller before reloading Mach3.

Some of the time- too often- when I tried starting Mach3, the ESS is of course Stopped at the start, but cannot be cleared except by exiting Mach3, cycling power, and trying again.  I don't have any idea what error condition it's responding to.  Yes it's supposed to start in the Stopped state, but clicking the flashing "Reset" inside Mach3 won't clear it.

Weirdly if I stall the motors by hitting a mechanical stop, Mach3 does end up in a Reset "emergency".  At first this seemed like a great feature, but I'm confused, because there IS no such feature.  The G540 does not have any stall-detection mechanism!  The power supply is a 48v 10.5A, stalling an axis shouldn't draw enough extra power to put that supply into current limit, I would think.  Actually if the ESS lost power due to the supply dropping out, I'd expect Mach3 to say "the ESS has not responded/timed out" that you get if you turn off the control box while Mach3 is running.  I could chalk that up to "some power or EMI thing" but I'm curious, and it MIGHT be related to why the ESS keeps getting stuck in Reset.

What can I do to make this start and operate reliably?

 

10

Modbus / USB RS485 modbus to X200

« on: August 07, 2014, 06:21:46 PM »

I have an X200 spindle, and a cheap USB-to-RS485 adapter:

http://www.ebay.com/itm/PL2303HX-Chip-USB-to-RS485-485-Converter-Adapter-Support-For-Win7-Linux-XP-Vista-/181488771511?pt=US_USB_Cables_Hubs_Adapters&hash=item2a4192e1b7

I saw the problem that the RJ45 connector selects 2 pins which are not traditionally a twisted pair with one another.  I cut the connector a few inches away and wired to the green/greenstripe twisted pair for the rest of a ~3ft cable.  These are the only 2 signal wires going to the X200.

I programmed the X200 for 8n1 19200 baud slave addr1.

I installed a "Modbus plugin" for Mach3. 

Under "Serial Modbus Test", Mach3 can open this Com port.  However, any Read operation gets me "CRC Error". 

I am not 100% sure I have the + and - pins of the Modbus correct, so I swapped them, then I get "Receive Timeout".  I am guessing this is outright the wrong polarity, but I'm not certain.

Any help?  I'm stuck.  I need basic communication to proceed.  I've spend considerable time diddling around with it and I have nothing to go on from here.