Hello Guest it is April 24, 2024, 06:03:35 PM

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

1161
General Mach Discussion / Re: Probe
« on: November 22, 2011, 08:21:17 AM »
As you've found, you have to set your feedrate high and your accel low otherwise you can't see what's happening. (It's still happening - you just can't see it). Here's the settings I'm using to show this issue. I use the X axis but it doesn't really matter because it's best done offline if your machine can't actually take the velocity value below.

Max velocity 15000mm/min, Accel 62.5mm/s/s (the lowest I can get Mach to take at that vel). Then run this:

F15000
G31 X5000
M666 (just displays var 2000 i.e. message getVar(2000))
M30

Now if I let it accel and get to approx X=1000 and then trigger AND HOLD the probe, Mach will start the decel ramp and eventually stop around X=1500 or so. The value in var 2000 is correct i.e. approx 1000 i.e. where it was first triggered.

Now do the same again but at approx X=1000 trip AND RELEASE the probe. Mach will again start it's decel ramp but when it stops the value in var 2000 is approx 1500 i.e. the same as the X DRO i.e. where it's come to a stop.

You can do this with no machine "attached" and you can either use a real probe, a switch or even with the keyboard using probe emulation.

Ian


1162
General Mach Discussion / Re: Probe
« on: November 22, 2011, 05:32:20 AM »
any deceleration settings in motor tuning are totally ignored when the Z Axis comes to a halt.

Not sure I understand what you mean Tweakie.

Anyway it seems my memory is not what it used to be - time to give it up and grow veg I think. I've mis-described the issue. I'll try again. If the trip (or as many trips as you like as it's decelerating after the first trip) is/are momentary i.e. bounced as per my original description of a "glancing blow", then the value stored is where the axis stops after decelerating and NOT where the trip occurred. HOWEVER if the last trip of several remains made (i.e. does not bounce) then the FIRST trip is what is recorded.

Ian

1163
General Mach Discussion / Re: Probe
« on: November 22, 2011, 04:29:14 AM »
HUM I have never seen it double write the trip point here.

Probably because you have decent acceleration and therefore don't notice it. Wind down your accel to a minimum and try it. As it's decelerating after the first trip, trip it again (several times if you like) . The appropriate var will be set to the position of the LAST trip. I've tested this a gazillion times when doing my probing routines with 3.42.20 - can't speak for other versions. Your milage may vary (arf  ;D).

Ian

1164
General Mach Discussion / Re: Probe
« on: November 21, 2011, 11:49:36 AM »
Just to add a little to Tweakie's excellent explanation. These type of probes are normally set as active high in Mach - i.e. whilst the contact is made the input is held low (by being grounded) and when a trip occurs, the circuit is broken thus allowing the internal pullups to take the input high (active).

Also there actually is a bounce issue to be aware of but it's not a big deal. As Tweakie says, the instant the circuit is broken, Mach (if using G31) stores the point of contact and then decelerates to a stop. HOWEVER - if the probe contacts are re-made and then re-broken during that decceleration phase, Mach will RE-WRITE that point as the point of contact. This is more likely if the trip is caused by "glancing" something to the side of the direction of travel for example. This only really becomes an issue if your machine accel/deccel is "poor" however. Whilst on the subject of "poor" decceleration, care must be taken to ensure that the probe overtravel capability is large enough to accomodate the slow down phase, otherwise.... CRUNCH. A useful addition to a home made probe is to add in an overtravel contact to trigger a limit - your probe gets to survive where others are assigned to the bin.

Ian

1165
General Mach Discussion / Re: Motors stall when using Goto Z's
« on: November 18, 2011, 04:47:03 AM »
Hi Hood - no probs. I've tried to get a definitive answer to this before with little luck. All I can say is I'm pretty sure that contrary to what seems to be a common belief, steppers actually "draw" the most current from the PS when stationary and this reduces with speed. That's why (very simply put) steppers eventually stall with speed.

lcluff2000

I'm not too worried running at half the rated power since the application will have little to no load.

This is slightly missing the point. Granted, at low speed you won't be "too" far away from the theoretical "optimum" torque (because of your phase current of 2.2A as opposed to the rated value of 2.8A). However as speed increases, your 24V is pitifully low compared to the ideal for your motors of 60V (if my calcs are correct). High speed torque is a direct function of Voltage. Even with "zero" load your motors would stall way below their potential maximum speed.

Also, it seems odd to me that the y-axis or z-axis will stall too even though they have different loads due to the design of the taig mill. Shouldn't there be a difference?
As above, the load isn't the real issue here.

Note that I've never had trouble jogging with any axis up to 45 IPM. I'm not sure why goto z's is different than jogging. Does anyone have any ideas for why these would be different within mach3? Is there a reason the resonance would be different with either method?

This is JMHO but with jogging, the Mach application isn't doing much. It simply tells the driver to jog - the driver's doing all the work independantly. With commanded moves, the Mach app is doing more. This *might* mean that the jitter is marginally worse. In a *good* system, this probably makes no difference. However, given you're "undercurrenting", "undervolting" and sadly your drivers are known to not handle mid band resonance as well as some other drivers, it may be just enough to cause the problems your seeing. Just a guess.

Just a quick comment re "rattlers". They do seem to work well with less than perfect drivers. With decent drivers that handle mid band resonance they (IMHO) bring nothing to the party. Personally I'd swap drivers rather than go the rattler route. As I said - JMHO.

Ian

1166
General Mach Discussion / Re: Motors stall when using Goto Z's
« on: November 17, 2011, 11:45:00 AM »
Hood - can you clear something up for me that's bugged me for years? I've seen this mentioned loads of times but just don't get it. How does running one axis use less current from the supply than when you run (say) all three? (and hence potentially cause a voltage drop). I can understand how that's the case with servos but with steppers I've always thought they "drew" the same current when stationary as when moving (in fact slightly more when stationary if we want to get picky). Maybe I'm wrong but if so I'm darned if I can understand why.

Ian

1167
General Mach Discussion / Re: Using M7 without interrupting G01
« on: November 16, 2011, 05:07:19 AM »
Reading between the lines this looks like the old problem that laser and 3D extrusion printer users face where they want to activate/deactivate the laser or extruder mid travel to avoid burns or over deposits.

This is exactly what Art created the E commands for but apparantly these got broken some releases back. One commonly used workwround was to use a spare axis DIR signal to toggle the required output.

It's discussed in various threads - here's one example. Tweakie's your man I think for this technique.

http://www.machsupport.com/forum/index.php?topic=18263.0

Ian

1168
General Mach Discussion / Re: Max speed Gecko
« on: November 01, 2011, 07:44:55 AM »
Actually the one disadvantage is G540 always run with 1/10th microstep...Microstepping is not user selectable...
Not sure why you see this as a disadvantage khalid. Anything much less than 10 and you won't get the advantages that microstepping brings to the party. Anything more than 10 and you're not only into "empty" resolution but also proportionally increasing the chances of microstep "clumping". Marris et al picked 10 for very good reasons.

Ian

1170
VB and the development of wizards / Re: File open dialog
« on: October 24, 2011, 12:04:07 PM »
Code: [Select]
Set objDialog = CreateObject("UserAccounts.CommonDialog")

objDialog.Filter = "Text Documents|*.txt|All Files|*.*"
objDialog.FilterIndex = 1 '*.txt is default
objDialog.InitialDir = "."
intResult = objDialog.ShowOpen
 
If intResult = 0 Then
    'user hit cancel
Else
    'filename is in objDialog.FileName
End If

Season to taste but beware - there be dragons - it'll work in XP but not much else.

Cheers

Ian