If you are shorting the pin to return/grnd at the port itself not the cable, then you may have a LPT card or MB problem. The port does not depend on an earth grng to function it has its own return path for all the active pins. If you did the test at the end of the cable then you may have a bad cable.

The only other thing I can think of is if you grounded all your components in a series ground instead of a star ground then you may see recirculated currents. Still it should not effect a good lpt port when checked at the port.

Just some thoughts, (;-) TP

Hi tp - problem sorted - see http://www.cnczone.com/forums/showpost.php?p=356556&postcount=8 onwards.

Now the only remaining problem I have is the possible bug with G31 so as soon as .57 is posted I'll give it a whirl.

Thanks TP - really appreciate your help and interest.

Stirling has the problem reoccurred since you corrected the problem with the signal???  We have run the G31 code for hours without error before. ? (;-) TP

Hi TP - yes it has.

I have a little routine to check the consistancy of my probe. It goes something like this:

G91
while I have nothing better to do
  G31 X10
  while ismoving()
  wend
  store touch point
  G01 X-5
  while ismoving()
  wend
wend

There's an object at about X5 so it just merrily bounces back and forth recording the touch point each time. Most of the time it's fine BUT - once in a blue moon it fails to execute the G01 and therefore doesn't back off. Actually - the first blue moon is round about 10 to 20 iterations in.

Ian

Ian, out of curiousity try using a G1 instead of the G01. I have seen sometimes that when running VB inside of mach it tends to get ahead of itself and forgets things.

(;-) TP

Tp - tried your suggestion. Just the same. Not sure where to go from here - think I'm stumped... but...

I have seen sometimes that when running VB inside of mach it tends to get ahead of itself and forgets things.

could you expand a little - this may be a clue.

In some VB programs (powerfeed for example) If you enter in more than 3 commanded moves at a time it seems that VB starts to overwrite the buffered code that is waiting to be used. If it overwrites far enough then it will seems to skip over sections of forgotten code and then only runs the most current code in the buffer.

BUT in your example it still points to a switch problem in the probe. I would program a single loop of VB code. I would then manually test the code one loop at  a time to see if the problem still occured.

If it did then I would program a single loop of code in GCODE and repeat it to see if it failed.

If it failed in VB but not gcode then it could be a VB problem.

If it failed in both VB and Gcode then you have a switch problem.

Have you tried placing a small capacitor across the probe leads to help the switch make/break the connection.  A lot of times with low voltage switching it is needed to keep the contacts working correctly.

Just some thoughts, (;-) TP

BUT in your example it still points to a switch problem in the probe.

Sorry TP but I don't understand your conclusion - A G1 command neither knows nor cares about the existance of a probe - or shouldn't do anyway.

Also now that I've littered my code with debugging traps and printouts I'm getting indications of all sorts of wierdness. Seems to me there are serious sync problems between the mach and vb threads and possibly even some corruption of the vb workspace by mach. Art has indicated he's aware of timing issues in the interaction between mach's implementation of G31 and vb. I'm beginning to think this is only the half of it.

Seems to me that the reason the bed o' nails approach is possibly more successful is more to do with the fact that g-code is static i.e. pre-created and is then run in Mach as per normal. With 2.5D probing the g-code has to be dynamic, i.e. created on the fly as it works round the profile. Clearly in this case the interaction between Mach and VB is more critical. Certainly more critical than Mach/vb seems to be capable of at the moment. Shame.

Whether V2.57 will solve the issue I don't know - any update yet?

The point was that given a long list of commands stored  in VB it overuns the buffer and appears to rewrite the buffer thus lossing some commands. Or so it seems.


So far the only time I have seen the g31 hang was if it did not trip or reset properly.

Just a thought, (;-) TP

OK - a bit of an update. After having found a way to kludge round the problems with G31/VB I now have a working 2.5D probing routine. My homemade probe's a bit crappy  so the resolution is no way as fine as I would like, but anyway - some progress! 

Haven't got into posting on youtube yet so in the meantime here's a couple of vids on my site of it probing (a french curve) and then running the auto-generated toolpath.

http://www.razordance.co.uk/probe25D.htm