[Jerry McFarland]

I tried to get GOTO working in gcode for Path Pilot and it would not work. I contacted Tormach and this is their response:

"The GOTO statement is not something we support in our G code interpreter. There are no current plans to add this feature."

Having GOTO would help me a lot for the project I am working on now. What do other guys think of this?

[cncwelder]

Given that Path Pilot is based on linuxCNC ( as discussed in multiple threads here), I would think that Tormach gave you the rational answer. Have you looked the various flow control mechanisms in LinuxCNC? I think they chose wisely. (Back in the day {MANY days ago!} there were still debates about the use of the goto statement in general programming - the BASIC guys sometimes seemed addicted to it while some hard core software development guru's called for it's removal from languages such as FORTRAN). Have you tried to refactor your code to use the flow control mechanisms (O-codes) used by LinuxCNC? I'd be surprised if you can't get the same functionality with little effort (think subroutines for instance). Good luck

[vmax549]

You can do a GOTO function in Lcnc but it is a contorted mess of code to do it. The combinations of call return can do it BUT it does exactly what a GOTO statement that is used by the rest of the world does . Linux CNC is KNOWN for developing contorted functions JUST to say it does not do it the way Fanuc does (;-) No G68 is another perfect example of this.

Get used to it IF you choose to use the PP. There are MANY ODD functions in it compared to the normal world of CNC. There is a reason most commercial users never liked EMC,EMC2,Lcnc.

(;-)TP

[cncwelder]

You can do a GOTO function in Lcnc but it is a contorted mess of code to do it. The combinations of call return can do it BUT it does exactly what a GOTO statement that is used by the rest of the world does . Linux CNC is KNOWN for developing contorted functions JUST to say it does not do it the way Fanuc does (;-) No G68 is another perfect example of this.

Get used to it IF you choose to use the PP. There are MANY ODD functions in it compared to the normal world of CNC. There is a reason most commercial users never liked EMC,EMC2,Lcnc.

(;-)TP

G'morning vmax549 - you pretty much illustrated the debate between developers who strongly adhere to structured programming principles (for generally sound reasons -think spaghetti code) and those developers who just want to get the code written (again for generally sound reasons). While I tend to fall into the structured camp, I do see both sides ( especially if the generated code base isn't going to need long-term maintenance). But I think these considerations influenced the decision to not include the unconditional jump in the LinuxCNC g-code interpreter rather than a desire to be different than the Fanuc variant (although I wouldn't presume to know the minds of the interpreter developers).

For a similar observation to yours, read the following link: https://www.mail-archive.com/emc-use.../msg53371.html .

[vmax549]

Sorry but the rest of the CNC control world tends to disagree with you as well. Gcode is NOT a highly structured coding system for doing many different functions . It only has one simple function, MOVE the machine. Goto has worked fine for the last 40 years and will work fine for the next 40 years in "GCODE". Making it HARDER to use does not always make it a Better application of code.

It is pretty well know in teh CNC world that EMC goes out of their way most times to NOT be industry compatible. It appears to be an ego thing with them.

BUT that is just my opinion after over 40 years in this trade (;-) Your mileage may vary do to local conditions.

(;-) TP

[cncwelder]

Sorry but the rest of the CNC control world tends to disagree with you as well. Gcode is NOT a highly structured coding system for doing many different functions . It only has one simple function, MOVE the machine. Goto has worked fine for the last 40 years and will work fine for the next 40 years in "GCODE". Making it HARDER to use does not always make it a Better application of code.

It is pretty well know in teh CNC world that EMC goes out of their way most times to NOT be industry compatible. It appears to be an ego thing with them.

BUT that is just my opinion after over 40 years in this trade (;-) Your mileage may vary do to local conditions.
(;-) TP

Ouch! - I seem to have touched a nerve. I really don't have a horse in this race, but I have been a satisfied user (not developer) of LinuxCNC for a number of years on a number of different machines. Having said that, I have followed the mailing list for interesting (to me) topics; I think it should be said that the g-code interpreter developers tend to be a very professional and dedicated group, interested in producing a top notch project. I would further think it's fair to say that some would like to see the language of machine control advance to the next level, and are of the opinion that g-code can be improved to meet that need; I personally think that influences some of the decisions made in the development effort. You can argue that g-code should not be this vehicle ( and that the developers should just produce a FANUC clone) , but stating the development decisions are driven by ego or "contrariness" does not seem justified to me. Just my opinion. If you really object to LinuxCNC's g-code interpreter that much, don't forget that you are free to download and fork the source - implement the unconditional jump however you want and build your version of LinuxCNC with your new interpreter. You can even see if there's interest in merging your modifications back into the "official" source. Having said that, I would reiterate that Tormach's approach has been very logical - contribute in those areas in which you have expertise (in Tormach's case, trajectory planner), and take advantage of the efforts of developers with expertise in others areas - everyone benefits from the group effort, and Tormach's customers benefit from very stable, mature, and efficient machine control. Cheers.

[vmax549]

Please don't get me wrong I have nothing against you (;-). It is just a discussion. NOW you just brought up the second most complained about part of the Lcnc project. WELL if you don''t like it you can program your OWN version. (;-) . Fanuc clone ?? well that has worked very well for MOST of the CNC industry thus far. AND it gives you platforms that operators can move back an forth between machine and still be familar with the operations of each one. There is nothing WORSE than trying to work on a machine that does everything but backwards to normal.

Change from Gcode. IF you can do it where it makes a better controller sure Many have tried and failed at that. BUT if you are just changing because you can what is the point Gcode works and has a very proven track record in over 40 years of use . IF it were left up to programmers to control Gcode we would have 50 different version just like there is about 50 different high end programming languages that all do about the same thing. One was created because they did not like the way the other dotted teh I or crossed the T . The end results being to switch a chip state from 1 to 0 or 0 to 1. EVERYTIME it changes it COSTs millions of dollars to implement and rarely does it improve anything... Like updating a PCs OS every year (;-) Yep it is a real money making time saver for someone but rarely the one that does the changing.

Changing JUST for the sake of change is NOT progress. It just delutes the entire Industry more and more every time.

It is funny that some in Lcnc advocate NOT to have a goto for Gcode but use it liberally in LCNC hal code. (;-)

NOW does it sound like I am against CHANGE ?? NOPE but ONLY if it is a REAL change not just a pyramid scheme for someone to make more money AND waste my time.

(;-) TP

[PCW_MESA]

It is funny that some in Lcnc advocate NOT to have a goto for Gcode but use it liberally in LCNC hal code. (;-)

There are no GOTOs or even any sequential structure in HAL

HAL is basically a connection plugboard between functional modules

[vmax549]

IF you go to the referenced discussion presented THEY internal users of Lcnc say there IS and even pointed it out. So are they wrong ???


QUOTED"" Just look at our beloved HAL code ( coded in C )
you will see lots of goto statements for error cleanup/messages.
makes the code easy to follow and clean.

besides if someone wants to write 'bad' gcode with gotos that
work, who are we to tell them how to program

Chris M

End Quoted""

(;-) TP

[PCW_MESA]

IF you go to the referenced discussion presented THEY internal users of Lcnc say there IS and even pointed it out. So are they wrong ???

(;-) TP

Anyone can say anything but if someone says LinuxCNC's HAL has a goto structure it would just be an indication that they have no idea what LinuxCNC's HAL does...

Basic HAL Reference

Sure there are gotos in _internal_ Linuxcnc code (though very few considering the size of the source code base)

As to whether gotos in a modern gcode dialect make sense its clear the LinuxCNC designers
decided to go in the structured programming camp direction. Thats their decision and ultimately
I think, a good decision.

[daniellyall]

this does show linux won't go the same root as most commercial machine controls,(won't there own method god knows why) problem with that if someone needs to use a goto they are pooped they have to do a work around. I don't use goto but a large % of cnc user`s do.
there is a reason most machine controllers use the same structure for the G code, it a simple reason. just as it`s a simple reason why most commercial machine`s, shop`s and controller`s wont use linux.

tormach are in a small market so it's fine for them but the big boy`s no.

and if you can`t work out why ask

[SCzEngrgGroup]

IF you go to the referenced discussion presented THEY internal users of Lcnc say there IS and even pointed it out. So are they wrong ???


QUOTED"" Just look at our beloved HAL code ( coded in C )
you will see lots of goto statements for error cleanup/messages.
makes the code easy to follow and clean.

besides if someone wants to write 'bad' gcode with gotos that
work, who are we to tell them how to program

Chris M

End Quoted""

(;-) TP

He's talking about the c code that actually implements the HAL functionality, not the HAL files the user sees.

Still, GoTo is very poor form, no matter the language. There is ALWAYS a better way to do it. In g-code, subroutines are a FAR better choice.

Regards,
Ray L.

[PCW_MESA]

I agree and I believe thats what the LinuxCNC developers wish to encourage at the user level

( Unless you have a rather odd CPU architecture, gotos will always be there _at some level_ though perhaps only the compiler writer will actually see them )

[cncwelder]

"NOW you just brought up the second most complained about part of the Lcnc project. WELL if you don''t like it you can program your OWN version. (;-) . Fanuc clone ?? well that has worked very well for MOST of the CNC industry thus far. AND it gives you platforms that operators can move back an forth between machine and still be familar with the operations of each one. There is nothing WORSE than trying to work on a machine that does everything but backwards to normal."

- That's the thing about open source (and LinuxCNC in particular): If you want a Fanuc clone for your CNC product, you can modify the g-code interpreter to be as close to Fanuc as you like! Yes, you are on your own in terms of merging it to future LinuxCNC releases, but there's nothing that says you need to update your controller software - if it's working well for your customers, then only update on your schedule. The other thing - there might already be someone out there who is doing this very thing -if so - why not collaborate? Only you can determine if the overhead of doing this makes financial sense vs. buying an OTS controller.

"Change from Gcode. IF you can do it where it makes a better controller sure Many have tried and failed at that. BUT if you are just changing because you can what is the point Gcode works and has a very proven track record in over 40 years of use . IF it were left up to programmers to control Gcode we would have 50 different version just like there is about 50 different high end programming languages that all do about the same thing. One was created because they did not like the way the other dotted teh I or crossed the T . The end results being to switch a chip state from 1 to 0 or 0 to 1. EVERYTIME it changes it COSTs millions of dollars to implement and rarely does it improve anything... Like updating a PCs OS every year (;-) Yep it is a real money making time saver for someone but rarely the one that does the changing."

- I understand your feelings. But remember - most developers in LinuxCNC are unpaid (for that activity)-they do what they do to "scratch their own itch". This means that the development effort WILL be developer driven - and most talented and creative professionals will not volunteer much time just to clone something else. I suspect that the expression "trying to herd cats" might be appropriate here. The trade-off: the reward of an unbelievably talented group of developers at an unbelievably low price.

"It is funny that some in Lcnc advocate NOT to have a goto for Gcode but use it liberally in LCNC hal code. (;-)"

- Again, as I noted above - a developer driven effort. The philosophy of the HAL developers may differ from the developers of the g-code interpreter. The beauty of the successful open source project is that the process actually works and can produce a remarkable product (linux itself comes to mind).

[kstrauss]

It sounds as though you have a project for which you feel that using a GOTO in your Gcode is highly desirable. Why not post a description of your problem? There are many here who can show you an alternate approach without GOTO.

BTW, does the RS274 standard include a GOTO command?

[vmax549]

HIYA Ray Most Gcode SUBS have goto/jump as well. (;-) Very hard to move around in Gcode without a goto or jump.What would be the reason to even have conditional Gcode IF you cannot goto or jump IT would be the same as using a SUB and there is NO advantage to that just a lot more coding to make it work. Heck you can even do it in Mach3 from a conditional macro I can jump to anywhere in the Gcode that I set up to jump to. Now it IS a one way jump BUT that is fine I do NOT need to return back to teh calling line. SAME with most Gcode you do NOT need to return.

(;-) TP

[Jerry McFarland]

Thanks for all the input regarding using GOTO. I agree that GOTO can result in messy code if you do not use it with restraint. I also would like to avoid it if possible. I was out of town for 1 day so I am late in responding back. Anyway, I pasted in my gcode below as someone suggested. So to summarize, I have a holding fixture for 11 parts for engraving a different letter on each part, that is A through K. So my program is working fine engraving the 11 parts. But what happens if part H is bad and I need to engrave it again? I load in another blank part H in the fixture and then It would be nice to jump over the unused subroutines. At this point I have to comment out the unused subroutines. Please suggest an alternate to using GOTO.
;--------------------------
g90 g0 x .220 y.526 z-.008;
o5001 call; set feed speed
o3001 call; A
m01
;---------------------------------
g90 g0 x 1.220 y.521 z0;
o5001 call
o3018 call; B
;---------------------------------
g90 g0 x 2.220 y.500 z.001;
o5001 call
o3035 call; C
;---------------------------------
; subroutines D through K continue below...

[PCW_MESA]

As a very simple example, using a "IF" conditional for each routine
based on a set of per routine parameters that are set at the beginning of the code
would accomplish much the same thing. You could probably do something clever for setting and
unsetting the subroutine enable parameters to minimize editing

Since you can do logic in expressions a conditional like
if [ #<DO_ALL> GT 0 OR #<DO_J> GT 0 ]
around the J block for example

Would allow simple redos of whatever block you needed

by setting the #<DO_ALL> parameter to 0 and #<DO_X> parameter to 1 (X is your A through K)
for all blocks that need to be re-done

[vmax549]

That is not a case to USE a goto senario. You just need to START the program from the proper line in the file to make your K part. I assume that the G90 line takes you to the Part offset. What does the o5001 do ?? o3035 ?? Are the subs part of the program OR are they outside subs called from the program ?

You could just edit in at the start of the file those lines needed to make the K part then M01 and edit out the code after you are done.

If they are outside subs just create a new file calling the needed subs to the needed offset. It would be 4-5 lines of code ??

(;-) TP

[Jerry McFarland]

PCW_MESA, thanks for the tip on using an IF statement: f [ #<DO_ALL> GT 0 OR #<DO_J> GT 0 ]. I will check into that, I have not used IF in gcode before.
vmax_549: Yes, G90 goes to part offset. o5001 sets g91 and f25. 03035 calls the engraving subroutine for letter C. The gcode I pasted in is part of the main program that calls subroutines. As you suggested I could copy the gcode for calling the K subroutine and paste it in at the beginning of the main part of the program adding an M01. That is a better way to do it and I did not think of that. Thanks!