Messages

1891

General Mach Discussion / Re: Missing steps at 10 ipm? Taig, Mach3, Xylotex

« on: March 03, 2008, 09:03:39 AM »

just a thought but what does your driver test look like with ref to what Art says in the vid?

1892

VB and the development of wizards / Re: Reentrant code

« on: March 03, 2008, 07:59:03 AM »

Hi Chris

Nice catch - In my view, you're absolutely correct - unless it's documented somewhere that VBA intentionally disobeys accepted standards for local variables - which I doubt very much. Clearly the folks at Cypress push 'n' pop the params correctly but not the standard locals.
This really is unacceptable. A while back I was having all sorts of strange behaviour in a probing routine, which I just couldn't make sense of and eventually had to totally code round it. I'm now thinking that CypressVB is simply not to be trusted - particularly in a 'safety critical' machine tool environment. I wonder what Brian's thoughts are on this - there must be other (correctly written) VB plugins out there that Mach could use instead.

Cheers

Ian

1893

General Mach Discussion / Re: usb to parallel

« on: March 03, 2008, 06:57:41 AM »

Hi Spanky
Chip's already said this but just to expand a little. Mach uses a drive protocol called "step and direction". i.e. to move a motor it needs to set a direction signal and send a step signal AT THE SAME TIME. So, to drive three motors for example it needs to issue SIX signals AT THE SAME TIME. It therefore uses the parallel port because without external hardware that is the only way that the many control signals can occur in PARALLEL. It has nothing to do with the SPEED of parallel ports v the SPEEED of serial ports. If you want to use Mach with USB which of course stands for Universal SERIAL Bus then you can only send signals SERIALLY. These SERIAL signals must then be collected up by external hardware into the groups that WOULD have been sent in PARALLEL. Once collected up by storing them until you have all signals required for ONE 'pulse slot' the external hardware will then issue these signals in PARALLEL to the motor drives. The only SPEED issue is that if you use a USB and the associated and required external hardware then the USB must be able to send data fast enough that the SERIAL data can be parallelized in the same time as a parallel port could have sent it.
Hope this helps
Ian

1894

General Mach Discussion / Re: Size and offset of Roadrunner

« on: February 29, 2008, 12:51:40 PM »

ahhhh got it wrong way round  - thanks Hood.

1895

General Mach Discussion / Re: Size and offset of Roadrunner

« on: February 29, 2008, 12:49:59 PM »

Hi kak

1. Stick a G21 at the beginning of the roadrunner file - it's programed for inches but you're in mm.
2. don't forget to regen toolpath

hope this helps

Ian

1896

General Mach Discussion / Re: How to test a parallel port.

« on: February 28, 2008, 04:52:46 AM »

Hi Barry - you haven't actually said what type of test you're wanting to do but here's a couple of example tests you can do with just Mach.

Short an input pin of port 1 to gnd and you should see the result on the diagnostics screen (Port 1 pins current state)
You can check port 2 by using the  getPortByte function call in a script. Similarly you can write to the ports outputs with putPortByte.

Cheers

Ian

1897

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

« on: February 27, 2008, 11:43:29 AM »

Hi gabi

It depends on whether you have Rhino3 or 4. If you have R4 I'm told this http://en.wiki.mcneel.com/default.aspx/McNeel/PointsetReconstruction.html works pretty well though because I only have R3 I can't use this or comment on it.

The way I did it in R3 (bound to be other ways too) is to use the drape command. Unfortunately you can't drape points. So the way I chose to do it was to convert the points into small planes - which you CAN drape.
So,  using the replace command in any decent text editor convert each point into a plane i.e. 26.00000,11.00000,0.12800 becomes _plane 26.00000,11.00000,0.12800 2 2 i.e. all your points become 2x2 planes, then just run the file as a command script in Rhino with "tools/commands/read from file" and it will create a "plane cloud". Then you just drape it. Voila.

A tip is to put _SetRedrawOff at the beginning of the command file and then _SetRedrawOn at the end - otherwise you'll need to go for a long walk whilst it's doing its thang. Hope this helps.

Cheers

Ian

1898

VB and the development of wizards / Re: Macro code problems

« on: February 26, 2008, 10:31:01 AM »

Hi Chris

1. elseif works as it should in VBA but no one seems to have told the CypressVB syntax editor "pretty printer" and so it stays black. FWIW I'd resist mixing 'elseif' with 'else if' if you value readability.

2. Can happen and more annoyingly the windows will stay "at the back" and will probably be called 'hidden' or something.

3. part 1: The Cypress debugger is nearly as sophisticated as its syntax editor.
   part 2: You should not declare Mach functions. like "code" for example.

4. Hmmmmm - I'm pretty sure this didn't used to be the case but I just checked and it does it on mine also. This would appear to be a feature and is of course quite wrong.

5. I know this is possible in a limited way in turbocnc for example but not (thankfully) in Mach - I've never understood why a "language" that has no means of input could possibly have any use for decision constructs. (OK there's G31 - but lets not go there)

Cheers

Ian

1899

VB and the development of wizards / Re: Code Execution order is reversed

« on: February 25, 2008, 10:53:59 AM »

Hi Chris

The VB under Mach is a little... well let's say idiosyncratic 

I suspect you are falling foul of the caveat in the UG because you are indeed effectively calling a script from within a script. The finer workings of Mach are of course only known to the inner sanctum of Art (retired) & Brian et al (not sure if there actually is an "et al" or whether its just poor Brian on his tod these days  )

So... You run your script. This is running in a separate thread to Mach. Your script sets #123 to 1 and then makes a "code" call to Mach - effectively requesting Mach to run mysub1.tap - Mach will do this in it's own good time. Meanwhile your script whips round the loop, sets #123 to 2 and requests Mach to run mysub2.tap which again, it will do when it's good and ready. Meanwhile your code whips round - sees i%=2 and jumps to the line after the next which is the end of your script - it closes down the thread.

Back to Mach - Mach looks on it's "VB request pending buffer" (my made up name for this bit of Mach) which I'm guessing is a stack (LIFO (last in first out)) rather than a queue (FIFO (first in first out)) and hence runs mysub2.tap. Of course by this time 123 is 2. That done it pops the next request from the stack - mysub1.tap and of course #123 is still 2.

FWIW you could try putting a "while isMoving() wend" construct after the call to "code". This will cause your loop to wait on a sync semaphore from the Mach thread before continuing. A reason why this may not work is that while your code is waiting, Mach will run your mysubX.tap. IF the VB interpreter is non-reentrant then it's still going to fail (which may be why there is the caveat in the UG).

This of course may be quite wrong - but it's my best guess.

Cheers

Ian

1900

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

« on: February 25, 2008, 07:09:37 AM »

I tried your routines and they actually work. I had to do a little tweaking to get them to work without mach throwing up a few errors but after a little fiddling they actually did work.

LOL - pleased to hear it Corwin - that was the idea 

A few suggestions I would make would be to have an option to offset the border by a selectable margin. This would enable the probe to get points at the zero plane. Or the border file could be combined with the point cloud to get those points.

Good point - I toyed around for quite a while with that thought but in the end I decided it actually didn't gain anything (I think anyway): For the points file to be of any use at all, you have to have CAD/CAM software that will load it as a point cloud and then be able to produce a 3D model from that cloud and ultimately create a toolpath from that 3D model. If you have the software to do that then telling it that the model's boundary is at the zero plane is trivial (usually a function of the "drape" option or whatever. These zero values are therefore redundant in the original points file.

Also I think a good addition could be making the point cloud a g-code toolpath that Mach could follow to replicate the object just scanned.

Absolutely right - but this is not trivial. If it could do this then the software would be moving well into the realms of CAM which it was never intended to be. I suppose it would be fairly trivial to create the gcode for a "bed o nails" type machining option but I don't think that would really be very satisfactory.

Just remember these are opinions from an armchair CNC guy that just started probing this week! I just might not know what I'm talking about!
-Corwin

Hey Corin - I really appreciate your comments - around 300 downloads and you're the first one to comment in a donkey's age.