Messages

1631

General Mach Discussion / Re: input read frequency?

« on: May 11, 2010, 04:35:32 AM »

Because torch height isn't controlled by G31....

At what point did I suggest it was?

It's a completely different, and less accurate, control loop. ONLY G31 behaves as I described.

That's what I'm trying to get at and obviously failing miserably... I'll try again as simply as I can...

If the G31 control loop tests the probe input at kernel speed then WHY does the THC control loop not test THC UP/DOWN inputs at kernel speed?

1632

General Mach Discussion / Re: input read frequency?

« on: May 10, 2010, 11:18:50 AM »

Ray

I'm not disputing anything you say. As I've already said, we established this earlier on in the thread.
By dynamic probing routine I mean one that determines at run time what it's next step will be based on previous steps.

But riddle me this. Why doesn't Mach *appear* to work in the same way with regards it's THC UP/DOWN inputs i.e. take a step and then check THC UP/DOWN ?

Cheers

Ian

1633

General Mach Discussion / Re: edge finding/2.5D probing

« on: May 10, 2010, 05:31:21 AM »

Hi Denis - I can see no reason for a "type mismatch" error at the moment and have never had it reported before. I'm going to have to do some close checking of the code and get back to you asap (bit busy at the moment though so it may be a while).

If you have a parallel port could you try it without the smoothstepper and see what happens?

Debounce is set top right of the config page in mach and has some effect on countering "dirty" switching - try increasing it and see what happens.

Cheers

Ian

1634

General Mach Discussion / Re: input read frequency?

« on: May 10, 2010, 04:56:44 AM »

I'm probably a bit slow and everyone else already knows this but... Re: probing - this must mean that in order to probe at the best resolution your machine is capable of you MUST probe at less than 10 steps per second right?

Ian

Probing is a completely internal operation, and probe input is sampled at kernel speed.  The 10Hz is the macro-pump rate, which has nothing to do with probing.

Regards,
Ray L.

At this point in the thread maybe so Ray (see my last post above yours) but at the time I posed the question the thread wisdom was that ALL inputs were read at 10Hz.

That said...

Probing is a completely internal operation

generally yes - but not in a dynamic probing routine and then the 10Hz macro rate really bites you in the ar*e.

Cheers

Ian

1635

General Mach Discussion / Re: input read frequency?

« on: May 09, 2010, 05:53:43 AM »

Hmmmm - I think we're maybe getting there. I'm beginning to suspect that MACH reads it's inputs much faster than 10Hz but that WE via VB or whatever can only access them at 10Hz or about - simply because that is the "activation" frequency of VB. Brains may be faster and perhaps plugins even faster but as I know nothing about either I can't comment. Certainly the index input MUST be read much faster, I suspect it's not alone not least because you can't just read 1 bit of a port - you get 8 bits min whether you make use of them or not. Clearly it makes sense that THC and probe inputs (and probably others) should be as fast as poss. Homing however probably doesn't actually need to be AS fast because it's a two stage process - fast followed by slow. The only crucial read is as it backs off the switch and this as we know is done sloooooowly - giving plenty of time for a read. Also as Hood has previously said I think - it's consistancy/repeatability that matters with home. Home is where home is and as long as it's the same each time - job done. Thanks for your input folks - I'm getting a better understanding now - I think!

Cheers

Ian

1636

General Mach Discussion / Re: input read frequency?

« on: May 08, 2010, 01:36:13 PM »

Anyway - back to my original reason for asking the question. Mach will raise and lower the Z for THC according to the inputs THC UP/DOWN. BUT - as the rate of update of inputs - i.e. THC UP/DOWN is only 10Hz then (for example) Mach could still be raising Z for a 1/10th of a sec after the THC UP has actually gone inactive. Not ideal. Yet from another thread active at the moment concerning the monitoring of spindle rpm, it would appear that the index input is special - i.e. it MUST be updating faster than 10Hz otherwise it could only monitor a well slow spindle. This seems strange - if Mach can handle the index input at a "decent" frequency - why not THC UP/DOWN? - Just trying to understand the implications for my own THC design.

Cheers

Ian

1637

General Mach Discussion / Re: input read frequency?

« on: May 08, 2010, 12:41:57 PM »

But what's the accuracy of your machine Terry?

1638

General Mach Discussion / Re: more port and pins question

« on: May 08, 2010, 10:51:46 AM »

Hi scrambled - have you ticked "Program Safety Lockout" as Hood advised?

Ian

1639

General Mach Discussion / Re: input read frequency?

« on: May 08, 2010, 04:56:43 AM »

I'm probably a bit slow and everyone else already knows this but... Re: probing - this must mean that in order to probe at the best resolution your machine is capable of you MUST probe at less than 10 steps per second right?

Ian

1640

General Mach Discussion / Re: edge finding/2.5D probing

« on: May 08, 2010, 04:51:04 AM »

I just thought that something was changing in this file when I click on "configure 2.5D probing routine".

No the file never changes. The configuration part just puts values in the registry which are picked up by G31Init in the macro which places those values in the gcode vars for probe25D.tap to pick up.

Another thing : Do I need a soft for the csv file (Excel?)

Not really, the .csv is used by the other functions in the software e.g. the 3D probing routine or the routine that creates the gcode to reproduce the perimeter you probed. That said you can look at it and make whatever other use of it you want. It's just a text file. The reason it probably has an Excel icon is that by default if you have excel it "grabs" the association.

Back to your OP...

I have an Y move until my probe touch, an X move, and always a mistake msgbox :"type mismatch"
The history file in Mach3 say: Error in line 44 :internal error <G31Fix>.

This has me stumped at the moment - I've never seen this error before nor has anyone else ever reported it.

All I can suggest at the moment is to increase your debounce, as the usual cause of strange errors is "indistinct" touches. Also until you get it behaving you could try a larger stepover. i.e. work on the basis of trying to get good solid switching of your probe at first.

Cheers

Ian