virtual methods in hal components ????

so I have been working on my toolchanger plans, and I have a pretty deep logic flow mapped out, I am curious about the limitations of hal component C code and virtual methods before I move to my next phase of code planning.

also are there any good example of virtual methods classes etc I can look at ? 

There are no virtual methods in C.

If you need runtime polymorphism in C, what is usually done is to use function pointers in structs. Without help from macros, that quickly becomes ugly.

I'm not a expert in c, so this is good info.


I'll look into that thanks

yeah, I'm working on the routines i want to call. breaking it into move linear, move rotary, I might integrate carousel i to it " that's conversation for another day" , and I'm working through the various mechanisms that are in common use that i can examine.

it's going to be a really complex component for sure. my first draft is going into my hurco slv40 in a few weeks, but I'm trying to make it extensible.

1 thing I'm looking for ideas about, is how to order the various subroutines in a hal file so they execute in sequence.

so there will be the various subroutines " pointers etc" and I'm looking for a way to make that configurable. i was thinking a some kind of array in the hal file the component can parse might work.

associate a move function to a number, out that in some type of data structure and have the component execute in that sequence.

I'm open to ideas here I've got a lot of the subroutines themselves written already


I'm definitely accepting code samples and links

To me, it is completely unclear what you are trying to achieve, why you want to do it from a C hal component and where those "virtual methods" come into play. Such a component is probably not the best first C project.

Control of a toolchanger is probably easier done and tweaked from within G-Code or python or the soft-PLC classicalladder.

tool changing with gcode is madness, and very dangerous.

I've already written a very functional tool changer program, that has error detection etc. the goal is to build a universal tool changer that can be used by anyone. programming in c isn't hard, but Linux CNC hal components have limitations . the basic premise is this, build a set of subroutines that will have a sequencer. 



if you don't have anything useful to contribute, why comment?

smc.collins wrote:

tool changing with gcode is madness, and very dangerous.

 

I am no expert here, and have exactly one fairly simple ATC (mostly) under my belt.  I'm using carousel.comp & gcode to manage it, but this doesn't seem any more or less suitable than something external to a gcode solution.

Tweaking/tuning the tool change process is certainly easier using gcode (assuming no C, python, or other programming skills).

Not being snide or snarky here.  Can you explain why tool changing via gcode is madness and dangerous? i.e. general principles which led you to that conclusion.

Are there conditions or machine configurations which are more or less likely to suggest that a non-gcode solution is preferred?

Does your conclusion extend to other machine accessories? - thinking bar feeders, pallet changers, part loaders... similar equipment.
 

If I thought my comment was useless I wouldn't have made it. My experience is also limited, I only integrated two toolchangers, a rotary one and a rack toolchanger, both with G-Code and the soft-plc. Not sure why you say that would be madness. All those move / wait / synchronisation stuff that you would need anyways is already there, it is visible, and easily adapted if the need arises.

What is madness is building a domain-language for toolchanging in a HAL-component in C. IMHO.