Messages

1191

General Mach Discussion / Re: Which CAD/CAM software for newbie

« on: May 16, 2009, 01:05:15 PM »

Hi Ray,  When I went to the Sheetcam websit the price was listed in Lear or something, paypal converted it to a bit over 300 dollars.  Never seen a thing about including a Mach liicense.  I will look again, I must of missed something.  jay

The pricing is in UK pounds, since SheetCAM is a UK company.

Regards,
Ray L.

1192

General Mach Discussion / Re: Which CAD/CAM software for newbie

« on: May 16, 2009, 12:15:38 PM »

I should have been mowing the grass or putting the new head gaskets on my girlfriends car but I got my CNC machine running today and never left it.  Ive held off on buying software till now so I need your help.  I will be getting the MACH3 license. Is LCAM anything I will actually use, the version with Mach trial doesn't seem to do much.  What CAD/CAM program would be good.  DO NOT say Autocad that ain't never going to happen.  I am not Bill Gates.  I have seen some use Sheetcam, it runs about 300 dollars which would be about the top of my budget.   I will eventually add a 4th axis so I need it to accommodate that, I want to do my own drawings and run them on my machine.  Load others files and work with them.  Could you send me in the right direction.   jay

I don't know how you got $300 for SheetCAM.  It's 170GBP = US$254, *INCLUDING* a Mach3 license.  It's a great piece of software, support is second to none, and it's constantly being improved.  SheetCAM TNG is REALLY nice, and includes a very handy simulation facility.  Not quite as much "eye candy" as Cut2D, but a LOT more functionality and flexibility for about the same money.  SheetCAM is made for milling, Cut2D is made more for routing and engraving.

Regards,
Ray L.

1193

General Mach Discussion / Re: Digispeed DC-06

« on: May 16, 2009, 10:26:55 AM »

Hi,

I have been using a home brew PWM to 0-10v converter for MACH3 to VFD spindle speed control for about 18mths,
the home brew works OK, the speed hunts a bit so decided to change to a Step - 0-10v Digispeed control.

I swaped over today, but I can only get the OP of the digispeed to vary 0.2 to 2v output.
As I change the speed via Mach, I can see the OP of Digispeed following but no more than 2v so I'm assuming the config is correct in mach. i.e swapped the PWM to step tick boxes and selected pin 14 in ports and pins as spindle.
The board has a solid 5v for the logic and a solid 10v from the VFD to power the analogue side.

I have adjusted the trim pot to max and fiddled with te spindle motor settings in te motor tuning page.
Also disconnected the analogue ip to the drive in case the VFD was dragging the analogue down, no change from the Digispeed though.

Bit stuck   (prob someting stupid I have done (good at that ) )

Anyone help please.

ATVB

Derek

Have you contacted Peter Homann at Homann Designs (DigiSpeed designer)?  He's usually very responsive.

Regards,
Ray L.

1194

General Mach Discussion / Re: X Y axis is opposite

« on: May 15, 2009, 08:43:30 PM »

Hello Everyone,

I just loaded my Mach3 software and it seems to be working OK except for when I want to Jog the X and X stepper motors. When I use the arrows in the Jog Screen they move opposite to the direction indicated. They are also opposite when using the arrow keys on the PC's keyboard. When I use the left arrow key for the X axis you'd expect the vice to move left but it moves right instead. I can't seem to find anywhere in the program where I can correct this abnormality. I'd really appreciate any help that anyone can offer.

Thanks
jessey

That's not an "abnormality", it's how it's supposed to work.  All movement is relative to the tool, not the work.  Jogging left moves the tool to the left, or the table to the right.

Regards,
Ray L.

1195

General Mach Discussion / Re: VB Is Laughing At Me....

« on: May 11, 2009, 10:47:21 PM »

Ray:

 yeah, I should have expected that. See its the way it buffers commands. When M1000 starts, that macro can add whatever it likes to the stream, BUT the macro commands added dont get done untill
Mach3 identifies that the first macro is finished, then the secondary command buffer runs whats in it, so while M1000 does add the command M1001 to the secondary command buffer, it wont actually
execute the command until it senses the M1000 has completed, then the M1001 will run as its holding in the secondary buffer...

   I suspect this is conditional for macro calls only. Code calls for other Gcode commands will ( or should ) execute immediatley before the next command in the VB macro runs. I do think work is being done
to change this and Ill tag this to discuss with Brian to see where it s going to go. There are some tricky technical reasons for that.. I just cant recall them at the moment, but I may be able to explain it better
when I discuss it with Brian, he's really the expert on where thats at, he did the multi threading of the VB,and very well I might add, but I think the macro calling macro was special for a very good reason.. Ill see if I can find out what that was for you.. Im a little rusty yin that section at the moment as I havent studied up on the new threading algorithms. Has somethign to do with the non-grouping of user macros as I recall..

Art
 

Art,

It would be really nice if there were a way to call a named macro, rather than just execute an M-code macro.  It would sure help make it easier to do more structured, readable macros.

Regards,
Ray L.

1196

General Mach Discussion / Re: VB Is Laughing At Me....

« on: May 11, 2009, 10:03:27 PM »

Ray:

 According to my Win7 installer, I have somethign liek 20 hours till I can do a test on this on my system.. , so what DOES happen? Im curious?

Art

Art,

It does exactly what you'd expect it to do if the M1001 macro is launched in a separate, parallel thread.  The messages come out:

M1000.m1s Start
M1000.m1s Done
M1001.m1s Start
M1001.m1s Done

Regards,
Ray L.

1197

General Mach Discussion / Re: VB Is Laughing At Me....

« on: May 11, 2009, 06:40:36 PM »

OK, I gotta ask. What is a semaphore?

http://lmgtfy.com/?q=semaphore

1198

General Mach Discussion / Re: VB Is Laughing At Me....

« on: May 11, 2009, 02:42:14 PM »

   VB macro's now, work much different than even a year agao, they are more linear now, and in fact one I think can call another with no semaphore requirement, as MAch3 only processes them one at a time.

Art,

Gotta strenuously disgree with you on this one.  Try the folliowing - create two macro files:

M1000.m1s:
Message "M1000.m1s Start"
Sleep 2000
Code "M1001"
Message "M1000.m1s Done"

M1001.m1s:
Message "M1001.m1s Start"
Sleep 2000
Message "M1001.m1s Done"
Sleep 2000

Then type M1000 into MDI.  If nested macros execute sequentially, as you suggest, and as logic would suggest, the status line should show "M1000.m1s Start", then "M1001.m1s Start" two seconds later, then "M1001.m1s End" two seconds after that, then, finally, "M1000.m1s End" two seconds after that.  That ain't even remotely what happens....

I put the semaphores in my macros because I simply could not get it to work any other way.  This really should be fixed, or at least documented.

Regards,
Ray L.

1199

General Mach Discussion / Re: CNC X and Y with manual Z?

« on: May 07, 2009, 10:13:20 AM »

Hello all,

I am fairly new to Mach3 and cannot find how to have Mach3 pause when the Z-axis need to be changed before the movement continues. Could someone let me know how this is done?

(I have tried to search the forums but could only find a post asking how to do it, but no answer to the question.  http://www.machsupport.com/forum/index.php/topic,2959.msg22873/topicseen.html#msg22873

Thank you.
Jerry

You don't indicate what CAM package you're using.  This can usually be handled easily by the CAM software.  SheetCAM provides a POST that replaces all Z moves with an M00, telling you what position to move Z to.  You move it, then hit CycleStart, and the program continues until the next Z move is required.

Regards,
Ray L.

1200

General Mach Discussion / Re: VB Is Laughing At Me....

« on: May 03, 2009, 10:54:30 PM »

Ray,
FYI - it was me (Dave) not Terry that asked about the semaphore usage - Since Terry stated (proudly  ) not to be a programmer, I suspect Terry is not a semaphore kind of guy. 

I'll believe that you found that you had to have them - and I admit that this worries me more than a little bit...

Since the cypress VB language offers no support for any type of critical section sync/locking mechanisms (at least not that I can find in the Cypress VB manual), this tells me that the use of VB level semaphores used can reduce the chance of failure, but not eliminate it (without lower level support for critical section locking, there are likely timing holes in the VB "semaphore code").

Not to play chicken little, but between nested macros, calls to Gcode for movement (which either falls thru or gets interrupted in the common wait for movement to end code), and no synchronization primitive support - this sounds like a recipe for dangerous, intermittent failures.

IF Mach is really mutli threading macro execution, then I fell rather distrustful of any nested macro scenarios.

To figure this out, I'd really like to know some key things, such as:

[I suspect these are Art or Brian questions... of course I get curious about this the week both Art and Brian were talking about vaction... :-(  ]

1) For Mach's gcode language, what modal group are user macros considered to be part of? (as given in the gcode modal group precedence table in the mach gcode reference chapters of the using mach manual).
This is important as there is no spec I can find that determines when a user M code word (i.e. user macro) executes within a block compared to other words in the block).

2) How does mach map execution threads to user macros?

Ray, did you ever see out of sequence operation within a single macro or only between nested macros?

Dave

Dave,

I only saw the problem with nested macros.  I simply could not find any other reliable means of ensuring a macro ceased execution until *all* lower level macros completed.  If you look at how I did the semaphores, I don't think there is any way for the nested macros to complete out of order, unless a low-level macro executes non-sequentially, which I cannot believe is possible.  With the semaphore mechanism, when a lower-level macro is invoked, it cannot do anything else until *all* lower-level macros have completed execution.  I've run a lot of hours with these, and never seen a single hiccup.  I did see all kinds of really squirrelly behavior before I put this mechanism in.  It did behave exactly as if each macro was running in its own unsynchronized thread, as goofy as that sounds.

Regards,
Ray L.