Remotely trigger jobs using the API?

[johannes]

I copied your GetSystemVariable C# code into my project and ran it without issue here. Tested with Offline 5.22 and Regular 5.22 and I always see the value as long as the Pipe is not broken. Did the same after converting to VB, no issues, always returns the value set by MDI as long as pipe is unbroken.

What version of CNC12 are you working with?

I rebuilt the project, and got it to work now Not entirely sure what was causing the problem, but now it responds with the correct values. (Using version 5.22).

However I am curious about the behaviour I am seeing:

When I check the SystemVariable via the API, it gets immediately set to the last instance of the variable when the job starts. I was expecting it to output "1" after it starts the Face operation, and only output "2" after it gets to the end. But in my case, it outputs "2" as soon as I start the job.
It seems like CNC12 is evaluating the entire file, and sets the variable to the last instance upon starting.

Am I inserting the variables wrong in the file to cause this?

Code: Select all

; ICN_PATH = C:\intercon\API_test_file.icn
; --- Header ---
N0001 ; CNC code generated by Intercon v5.22
; Description: API Test File
; Programmer: Johannes
; Date: 08-Dec-2024
  M25 G49 ; Goto Z home, cancel tool length offset 
  G17 G40 ; Setup for XY plane, no cutter comp 
  G21 ; millimeter measurements 
  G80 ; Cancel canned cycles 
  G90 ; absolute positioning 
  G98 ; canned cycle initial point return 
; --- Face ---

#29110 = 1

N0002 G0 X0.0 Y0.0 Z2.54
  G1 X0.0 Y0.0 Z-7.54 F1155.0
  X30.0 Y0.0 Z0.0 F11700.0
  X0.0 Y16.0 Z0.0
  X30.0 Y0.0 Z0.0
  X0.0 Y12.0 Z0.0
  X-30.0 Y0.0 Z0.0
  G0 G90 X0.0 Y30.0 Z2.54

#29110 = 2

; --- End of Program ---
N0003 G49 H0 M25

  G40 ; Cutter Comp Off 
  M5 ; Spindle Off 
  M9 ; Coolant Off 
  G80 ; Cancel canned cycles 
  M30 ; End of program 

[Centroid_Jacob]

Yep, It would seem the lookahead function is evaluating those variable before we actually get to the line of G-Code, you should modify your job as such to avoid this:

Code: Select all

; ICN_PATH = C:\intercon\API_test_file.icn
; --- Header ---
N0001 ; CNC code generated by Intercon v5.22
; Description: API Test File
; Programmer: Johannes
; Date: 08-Dec-2024
  M25 G49 ; Goto Z home, cancel tool length offset 
  G17 G40 ; Setup for XY plane, no cutter comp 
  G21 ; millimeter measurements 
  G80 ; Cancel canned cycles 
  G90 ; absolute positioning 
  G98 ; canned cycle initial point return 
; --- Face ---
IF #50001 THEN ; Prevent lookahead from parsing past here
#29110 = 1

N0002 G0 X0.0 Y0.0 Z2.54
  G1 X0.0 Y0.0 Z-7.54 F1155.0
  X30.0 Y0.0 Z0.0 F11700.0
  X0.0 Y16.0 Z0.0
  X30.0 Y0.0 Z0.0
  X0.0 Y12.0 Z0.0
  X-30.0 Y0.0 Z0.0
  G0 G90 X0.0 Y30.0 Z2.54
IF #50001 THEN ; Prevent lookahead from parsing past here
#29110 = 2

; --- End of Program ---
N0003 G49 H0 M25

  G40 ; Cutter Comp Off 
  M5 ; Spindle Off 
  M9 ; Coolant Off 
  G80 ; Cancel canned cycles 
  M30 ; End of program 

[johannes]

Yep, It would seem the lookahead function is evaluating those variable before we actually get to the line of G-Code, you should modify your job as such to avoid this:

Code: Select all

; ICN_PATH = C:\intercon\API_test_file.icn
; --- Header ---
N0001 ; CNC code generated by Intercon v5.22
; Description: API Test File
; Programmer: Johannes
; Date: 08-Dec-2024
  M25 G49 ; Goto Z home, cancel tool length offset 
  G17 G40 ; Setup for XY plane, no cutter comp 
  G21 ; millimeter measurements 
  G80 ; Cancel canned cycles 
  G90 ; absolute positioning 
  G98 ; canned cycle initial point return 
; --- Face ---
IF #50001 THEN ; Prevent lookahead from parsing past here
#29110 = 1

N0002 G0 X0.0 Y0.0 Z2.54
  G1 X0.0 Y0.0 Z-7.54 F1155.0
  X30.0 Y0.0 Z0.0 F11700.0
  X0.0 Y16.0 Z0.0
  X30.0 Y0.0 Z0.0
  X0.0 Y12.0 Z0.0
  X-30.0 Y0.0 Z0.0
  G0 G90 X0.0 Y30.0 Z2.54
IF #50001 THEN ; Prevent lookahead from parsing past here
#29110 = 2

; --- End of Program ---
N0003 G49 H0 M25

  G40 ; Cutter Comp Off 
  M5 ; Spindle Off 
  M9 ; Coolant Off 
  G80 ; Cancel canned cycles 
  M30 ; End of program 

Does preventing lookahead impact the speed of processing / mill performance?

[Centroid_Jacob]

Yep, It would seem the lookahead function is evaluating those variable before we actually get to the line of G-Code, you should modify your job as such to avoid this:

Code: Select all

; ICN_PATH = C:\intercon\API_test_file.icn
; --- Header ---
N0001 ; CNC code generated by Intercon v5.22
; Description: API Test File
; Programmer: Johannes
; Date: 08-Dec-2024
  M25 G49 ; Goto Z home, cancel tool length offset 
  G17 G40 ; Setup for XY plane, no cutter comp 
  G21 ; millimeter measurements 
  G80 ; Cancel canned cycles 
  G90 ; absolute positioning 
  G98 ; canned cycle initial point return 
; --- Face ---
IF #50001 THEN ; Prevent lookahead from parsing past here
#29110 = 1

N0002 G0 X0.0 Y0.0 Z2.54
  G1 X0.0 Y0.0 Z-7.54 F1155.0
  X30.0 Y0.0 Z0.0 F11700.0
  X0.0 Y16.0 Z0.0
  X30.0 Y0.0 Z0.0
  X0.0 Y12.0 Z0.0
  X-30.0 Y0.0 Z0.0
  G0 G90 X0.0 Y30.0 Z2.54
IF #50001 THEN ; Prevent lookahead from parsing past here
#29110 = 2

; --- End of Program ---
N0003 G49 H0 M25

  G40 ; Cutter Comp Off 
  M5 ; Spindle Off 
  M9 ; Coolant Off 
  G80 ; Cancel canned cycles 
  M30 ; End of program 

Does preventing lookahead impact the speed of processing / mill performance?

I checked in with this and we believe you shouldn't see any impact with speed or performance with normal operation with the exception of G-Code Smoothing. For advanced smoothing calculations, there may not be enough time to make the calculations before the smoothed move.

See cncsnw's response below for better information than I gave.

[cncsnw]

There may be a misunderstanding here over what "preventing lookahead" really means.

Inserting a line with "IF #50001" does not turn off lookahead for the rest of the program. This is not a modal setting.

Instead, it forces the G code parsing process to stop reading at that line, and to wait until all preceding lines have finished executing, before it resumes processing the remaining lines.

Of course, if you inserted such a line in the middle of a series of cuts, it would cause the control to decelerate to a stop; pause briefly as it buffers the next set of moves; and then start moving again.

But inserting a line like that at the beginning of a program, or at a point where motion is stopped anyway while waiting for a tool change or other I/O operation, isn't going to affect motion at all. At most it will cause a brief pause at that point.

[johannes]

This is coming together really well, and I have now completed most of what I needed. I can select a job, set It to run, and monitor it as it runs, check for error messages, and verify that it successfully completed.

(This --> is NOT how I intend to use the API, but I added some of the fields to a basic web page just to test the connection. Seems to work fine: https://centroid.plasmic.run. This is connected to my AcornSix on the bench, and talks to CNC12 using the RestAPI that wraps the CentroidAPI.)



One thing I am stuck on though is updating Part Zero. I need to adjust X-zero in between runs, and I was expecting this to work:

CentroidAPI.CNCPipe.Wcs.SetWorkpieceOrigin (int wcs, int axis )

However, whenever I attempt, I get a SUCCESS code back, but Part Zero does not update as I had expected. I had expected DRO for G54 to read 0.000. I have tried multiple variants of WCS numbers and Axis numbers, but no difference. Nothing takes effect, but the return message is "Success".

Perhaps related (?), when I query for
CentroidAPI.CNCPipe.Wcs.GetActiveWcs , the output is expected to be a number between 1-18, but I get a 0.

[Centroid_Jacob]

This is coming together really well, and I have now completed most of what I needed. I can select a job, set It to run, and monitor it as it runs, check for error messages, and verify that it successfully completed.

(This --> is NOT how I intend to use the API, but I added some of the fields to a basic web page just to test the connection. Seems to work fine: https://centroid.plasmic.run. This is connected to my AcornSix on the bench, and talks to CNC12 using the RestAPI that wraps the CentroidAPI.)
This looks really good for a test! Thanks for sharing!


One thing I am stuck on though is updating Part Zero. I need to adjust X-zero in between runs, and I was expecting this to work:

CentroidAPI.CNCPipe.Wcs.SetWorkpieceOrigin (int wcs, int axis )
However, whenever I attempt, I get a SUCCESS code back, but Part Zero does not update as I had expected. I had expected DRO for G54 to read 0.000. I have tried multiple variants of WCS numbers and Axis numbers, but no difference. Nothing takes effect, but the return message is "Success".
This is a bug, thanks for bringing this to our attention.


Perhaps related (?), when I query for
CentroidAPI.CNCPipe.Wcs.GetActiveWcs , the output is expected to be a number between 1-18, but I get a 0.
GetActiveWCS returns 0 indexed selected WCS, so if you have WCS#1 Selected it will always return 0. Change WCS from Setup > Part > WCS Table > Origin (or keyboard shortcut Alt +) and it should change the index returned. Confirmed working with v5.22

[johannes]

This is a bug, thanks for bringing this to our attention.

Ok, happy to know it's a bug, and not my mistake. Thanks for confirming.

CentroidAPI.CNCPipe.Wcs.GetActiveWcs , the output is expected to be a number between 1-18, but I get a 0.
GetActiveWCS returns 0 indexed selected WCS, so if you have WCS#1 Selected it will always return 0. Change WCS from Setup > Part > WCS Table > Origin (or keyboard shortcut Alt +) and it should change the index returned. Confirmed working with v5.22

The documentation is perhaps a bit unclear, then? Since it seems to indicate that the valid output is 1-18.

[Centroid_Jacob]

The documentation is perhaps a bit unclear, then? Since it seems to indicate that the valid output is 1-18.

Yes, it would seem the documentation is incorrect. This will be fixed in the next release.
Edit: Its less incorrect and more unclear. GetActiveWCS returns the selected enumerator of WCSes. In my testing, I was returning the int value instead of the enum so technically yes it is 0 based but returns a 1-18 enum. This will be cleared up in the next release regardless but felt I should correct the information I provided.

Code: Select all

public int GetActiveWCS()
{
    var cncWCS = new Wcs(m_pipe);
    Wcs.WCS wcs_number;
    cncWCS.GetActiveWcs(out wcs_number);
    return (int) wcs_number;
}

We have a test DLL to send you that should fix the bug with "SetWorkpieceOrigin (int wcs, int axis )", you should get an email shortly containing the new DLL and instructions.

[johannes]

We have a test DLL to send you that should fix the bug with "SetWorkpieceOrigin (int wcs, int axis )", you should get an email shortly containing the new DLL and instructions.

I can confirm the new DLL fixed this. Thanks for the quick response!