Messages

11

General Mach Discussion / Replicating Parts

« on: November 15, 2009, 09:25:15 AM »

I have a part that uses 25 toolpaths. I designed it in Aspire and would now like to cut multiple parts from a single sheet of material. I don't want to have to redo all of the toolpaths in Aspire when I replicate the parts onto the sheet. Is there any way in Mach to load a g-code file and then tell Mach to run i multiple times at differnet x and y offsets?

12

General Mach Discussion / Re: Unexplained Stops

« on: November 06, 2009, 10:12:33 PM »

Not so much a message box but it has all sorts of messages like IsStill etc see which ones have a check in them when it happens again.
Hood

I see that the IsStill indicator is on. I guess that tells me that the SS knows it is stopped, but I still do not know why. Anything else I should be looking at?

13

General Mach Discussion / Re: Unexplained Stops

« on: November 04, 2009, 06:03:31 PM »

Do you get any mesages on the SS Diagnostics page when this happens?
Hood

I looked at the diagnostics page when this happened and didn't notice a message. But then again, I didn't even notice a place for a message. I will look again.

14

General Mach Discussion / Unexplained Stops

« on: November 04, 2009, 05:36:20 PM »

I am running a SmoothStepper, which may or may not have anything to do with this problem. When I am cutting the machine will sometimes stop for no reason. It is not in e-stop. I can click run and it will start immediately from the point it stopped.  Any ideas on what is happening?

15

General Mach Discussion / Must X and Y Have Same Acceleration

« on: October 11, 2009, 11:10:27 PM »

Will there be any problem with using different motor tuning acceleration parameters for the X and Y axis. Just wonder if there would be strange results if, for example, cutting a circle at a high speed or if rounded corners would be asymmetric if Constant Velocity mode is used.

16

General Mach Discussion / Re: G4 versus Sleep

« on: October 08, 2009, 05:13:12 PM »

OK..hopefuly I am about finished asking questions on this. The original code had a G4 P0.5 command after any DRO update. Given all I have learned from that thread, it sounds like that command could not be doing as intended. But then again, I am not sure what the problem was that casued the need for this to be added. Perhaps this is code developed long ago that no longer applies.  It sounds like I should actually use a Sleep 100 (or perhaps add some, say Sleep 120) to make ure that Mach has made it through its 100 msec loop). Do people normaly add a sleep command after any DRO update?

CAN'T WAIT FOR VERSION 4...just hope it plays well with a SmootStepper!

17

General Mach Discussion / Re: G4 versus Sleep

« on: October 08, 2009, 04:17:18 PM »

Can you use IsMoving to see that a DRO has finished updating. I wouldn't call a SetEOMDRO command G-code, so I am wonderig if IsMoving will be a good way to detect that the DRO has finished being upadted.

18

General Mach Discussion / Re: G4 versus Sleep

« on: October 08, 2009, 01:30:28 PM »

I nkow this sounds like I am asking the same queston, but it is a little different. The zero touch plate probing routine I was modifyig was originally written by someone else. In that code, anytime a DRO was changed they added G4 P0.5 with a comment that said "pause for the DRO to update." Based on the feedback from this thread, I don't think the G4 command was the appropriate one to use, but rather a sleep command should have been used to pause on the VB side. However, rather than have a fixed pause, I'd like to add this code after a DRO is updated:

While IsMoving ()
  sleep 10
Wend

My question is: does "IsMoving" apply to a DRO update? If so, I would think I could add the While IsMoving loop and do things fatser than having a fixed pause.

Thanks for all the help!
Kent

19

General Mach Discussion / Re: G4 versus Sleep

« on: October 06, 2009, 10:25:46 AM »

Mach and VB exist in two distinct asynchronous threads. VB (the client) issues requests to Mach (the server). G4 runs in the Mach thread, sleep runs in the VB thread. Requests are not neccessarily run by Mach in the order they are sent by VB. Mach decides on the priority of the request i.e. in which order all the currently queued requests will be run. gcode is higher priority than updating the display.

isMoving() is arguably mis-named - it doesn't neccessarily have anything to do with axis movement, it might have been better if it were called "MachIsBusy()"

Hope this helps

Ian

Yes, this helps very much! I was wondering if the IsMoving was really more than an indication of an axis moving. So I am still not sure when to use sleep versus G4, but I think I have come to one conclusion. Whenever you make a change to Mach, such as changing a DRO, the coordinate system, etc AND you have subsequent code that relies on those changes to be made, you should always add a While Is Moving loop after those changes to make sure Mach has completed them.  Is this correct?

Thanks,
Kent

20

General Mach Discussion / Re: G4 versus Sleep

« on: October 06, 2009, 09:56:17 AM »

Hood..I am so glad you jumped in on this.

Actually that is how I first fixed the problem. I added:

While IsMoving()
Wend

After I issued:

 Code "G90"
 DoOEMButton (180)

That fixed the problem and led to the begining of my confusion. Nothing should be moving due to the G90 and OEM Buttom (180) commands, but yet the While IsMoving loop fixed the problem.  It seems the G4 P command is not effective at doing what I think it should be doing. I am tempted to replace all G4 P commands with the equivalent Sleep delay. I having been digging through this forum for a while and cannot figure out when the G4 P (dwell) command should be used versus the sleep command. I am also reading that sleep is no longer neede in the While IsMoving(), Wend loop.

I will greatly appreciate your insight on this.

Kent