Messages

1

General Mach Discussion / Re: G31 Probe problem

« on: December 07, 2011, 02:48:07 AM »

Thanks guys nice to know its not just me or my machine going crazy

I would not have stumbled on the G31 issue except for the fact that we (Dave and I) were debugging a different issue with MSM that cropped up if the probe was active prior to starting a probe routine.

That has since been fixed and as I do all my probing using the MSM interface and have had no issue with it as yet I would have been blissfully unaware of the G31 quirk.

Haven't done any point cloud type probing yet but its on the soon to do list of jobs. Hopefully this quirk won't cause dramas with that.

Cheers
Mark

2

General Mach Discussion / Re: G31 Probe problem

« on: December 06, 2011, 08:57:02 PM »

Speaking of multi threading... which is possibly what I'm doing posting my bug report here is doing although suspect it is related...

Further testing exhibits the following:


Scenario 1
probe active
machine axis not referenced
issue : f1000 g31 x10
displays a probe ignored warning
delay then displays safe Z height warning
no movement
Scenario 2
probe active
machine referanced
issue g31 x10
displays a probe ignore warning
delay ~ 2.5 minutes
display safe z warning
move all axis one at a time as if in a RefAll
rinse and repeat last 4 lines
It continues to do a RefAll type movement every 2 odd minutes as if in a loop with no external inputs??? I can hear it do its dance as I write this post

If while it is doing this infernal loop you remove the probe input Mach will (after finishing its loop into fairy land) move to its inital position prior to the G31 error and RefAll move. I have been using .037 and just updated to .053 but going back thru the change log this one caught my eye....

March 17/2009 Release 3.042.023 -- Threading bug found and fixed in Driver... -- Probe error know kills script and file execution

Is it possible that this was not fixed or has crept back int later versions?

3

General Mach Discussion / Re: Homing offsets for slaved axes

« on: December 05, 2011, 05:37:24 AM »

Same issue for me.. inductive sensor etc. I had plans of putting a rotary encoder on the arse end of my X axis steppers as they are dual shaft but not doe it yet. and I have a set of servos on the shelf that I really should try out. Somehow need a fixed in space index pulse off the drive... because as you say if the home sensor is not repeatable then its no use having an offset as it would need to constantly change. Also if its not repeatable its not a good choice as our initial index pulse... so that negates a bit of what i was suggesting before.

BTW I agree 100% about the homing routine.. not a big fan in its current form as it does rack the gantry slightly the way it works at the moment. Posted a request to get a change ahiile back (SS issue) but at the time backlash comp was the big todo item.. not sure if Greg has had a chance to revisit this yet. If you find out where the step off distance is hidden please give me a heads up.

As to Mud...
To clarify.. or at least attempt:
Say you have an encoder and and an index pulse and you want to have the index at a precise position in the rotation. You have two choices.. mechanically rotate and fix the encoder to the shaft in precisely the correct position or recreate a new index pulse "n" encoder pulses later. Using a counter circuit allows you to do this.
Using the actual prox as the enable or gate signal to make the delayed index valid.

4

General Mach Discussion / Re: Homing offsets for slaved axes

« on: December 05, 2011, 05:13:05 AM »

Just had another thought.. if you don't have encoders on your stepper or a servo setup the you could possibly use the step input to your drives as the clock signal. Note also with a single 8 bit counter you have up to 256 count delay .. cascade another one and you have heaps (64k) of possible delay. You would only need to do this to the side that has the sensor that is normally triggered first.

You may also need to put a counter in for the deactivate position as I believe that is where Mach sets its zero .. plus a step off amont... which I'm currently trying to find out how to set.

5

General Mach Discussion / Re: Homing offsets for slaved axes

« on: December 05, 2011, 04:24:32 AM »

Hi Matty

Not a fix but you should consider the fact that you will be racking your gantry every time you home even if it is possible to have different offsets.... might make the effort in making the home switches adjustible.

For a hardware fix and something I will do when I finally put servos on my machine how about this... use the home sensor as a gate/load signal to an up/down counter with a preset number (selectable via dip switch) and have the terminal count signal be latched as the new "repositioned" home signal. Clock signal for the counter is from the encoder on the axis.

Clear as mud? This works very well and I used to use this to reposition the index pulse on high end imagesetters I helped design.

Cheers
Mark

6

General Mach Discussion / Re: G31 Probe problem

« on: December 05, 2011, 03:53:17 AM »

Got a weird one for all you experts...

For referance I'm using a Smoothstepper.

Stumbled on this when I had a probe failure (ie probe was stuck on) and while testing found another "feature"

Here is the scenario:

Probe is already active and you issue either a G90 or G91 G31 X10 to which the machine will not move as the probe is already active and will display a warning message.

Fix probe so that it is now inactive and resend same command G91 G31 X10 and again nothing happens but no warning message... however with no other imput approximately 2 minutes latter the machine executes what appears to be a RefAll and then the original G31 move.

Want one step stranger.. issue the G91 G31 X10 command twice after the initiall fault and fixed probe and after 2 minutse it does the RefAll and return to G31 command twice!

Have I stumbled onto a Mach blackhole? Very strange... anybody else able to duplicate this "feature" ? BTW play safe and make sure that it can do the moves without crashing.

Bemused

7

Mach SDK plugin questions and answers. / Re: XBox360 Controller Plugin Version 2.3.8 Now Available

« on: October 18, 2011, 05:12:08 AM »

Here's the site of the chatpad driver (wired version):

http://www.mp3car.com/hardware-development/140189-contest-xbox-chatpad-driver-challenge-65.html

I've not tried it though as I have a wireless one.

8

Finished Plugins for Download / Re: Huanyang VFD controller plugin

« on: September 26, 2011, 06:00:00 PM »

You can see the response in spindle talker, in most cases it will reply by repeating with the same info.

9

Finished Plugins for Download / Re: Huanyang VFD controller plugin

« on: September 26, 2011, 04:32:59 PM »

Yep that's it. and yes it is VERY poorly written. took ages to decipher what they were trying to say.
Experimentation found that data of 1-5 all were CCW start commands and 9-D were CW start commands. 8 was stop and it appears that these are the only 3 control datra commands that can be written.

I was going to ask my mate Wayne to add a function to spindle talker that would read and store all the PD values and also restore them from backup but have yet to get around to that.

To read what the current draw is or the actual rpm then a 04 (read control status) is used as shown on page 57.

10

Finished Plugins for Download / Re: Huanyang VFD controller plugin

« on: September 25, 2011, 09:25:26 PM »

Here ya go


Start CW    01 03 01 01 31 88            (VFD address 01, write control data 03, data length 01. data 01, checksum 31 88)
Start CCW  01 03 01 11 30 44
Stop          01 03 01 08 F1 8E
Set Speed  01 05 02 9C 40 D0 3C         (05 is write frequency control data (2 bytes))  9C 40 Hex =  40000 or 400.00 = 24000rpm