Jogging within a Macro

[loesch]

I saw another post about something similar, but no solution. I wrote a macro for my XY webcam to set work origin with offsets to the real tool location. Since my webcam (a small USB boroscope type) isn't perfectly parallel to the Z axis (yes, I've tried), the XY crosshairs in the webcam window move some when Z changes. My solution is to probe and set a fixed height over my workpiece. I wanted to have everything in one macro (probe, set height, jog to origin, apply offsets), but my problem is that once I'm in the macro, the UCCNC jogging window is disabled. Is there anyway to make a call to re-enable the jogging window? Don't know if it was disabled or if the macro world is isolated from the rest of the UCCNC world.

[beefy]

Could you try creating some "on-while-clicked" screen buttons for jogging, then your macro can scan those buttons in a loop and call the built-in jog button codes, e.g. button code 147 is JogX+.

The big question is..........are these disabled while running a macro.

You could have another screen button that is click to on, click to off. This button is also scanned in the above mentioned loop. When your position is correct you click this button to on. The loop then knows your position is correct, exits the loop, and moves on to do it's next thing. At the end of the macro this button is automatically set back to off (i.e. by the macro code).

Cncdrive, or other members may have a simpler/better idea.

[loesch]

Well, I haven't solved the problem of the jogging screen not popping up (out) when a macro is running, but I found a work around. My handheld pendant still works, so I can use that to move the carriage during macro operations in lieu of the built-in jogging screen. While my problem is essentially solved, I do feel that a way to make the pop-out window operational would be helpful, especially for those that don't have a pendant.

[beefy]

I think the reason the jog window is disabled during macro running is in case your macro is commanding a move and then the user is trying to tell the system to do a different move via the jog buttons.

That's why the safe way may be what I suggested in the previous post. The macro only commands a jog move when it's ready and the user is pressing the custom buttons.

[loesch]

beefy, your suggestion would definitely work, but I didn't want to essentially program another jogging screen. I would need to jog at different speeds, faster to get in the vicinity of my new location, and then slow down as I approach the correct location. I looked, but couldn't find the system code for the build in jog screen.

It would be nice if there was a form of wait state in the system that could be called that would allow the jog screen, and then a release of the wait state afterwards that again disables it. Just a thought. Thanks for the assist.

[dezsoe]

The jogging is disabled while a macro is running. It's normal: your macro may run g-codes and jogging while a g-code is running would be interesting. If you want to do everything in one macro then, I think, the best way is to have that main macro with all the code in it and the different buttons that call this macro with a parameter showing wich button was pressed. E.g.:

Button 20000, M20000.txt: exec.Code("M20100 Q1");
Button 20001, M20001.txt: exec.Code("M20100 Q2");
Button 20002, M20002.txt: exec.Code("M20100 Q3");

M20100.txt:

Code: Select all

int Qint;

if (Qvar == null)
{
  return;
}

Qint = Convert.ToInt32(Qvar);

switch (Qint)
{
  case 1:
    // code for 1st button
    break;
  case 2:
    // code for 2nd button
    break;
  case 3:
    // code for 3rd button
    break;
}

#Events

static int myIntVar;
static double myDoubleVar;


(See this post about why to use statics. You don't need to precompile the macros.)