[deadlykitten]

hello everybody overloading involves sending, to a same named soubroutine, different types ( or number ) of arguments ( osp variables )

in other words, the CALL statement is variable, but not like a parametric soubroutine, which always deals with a fix number of variables, but with different values

a parametric soubroutine delivers kind-of similar behaviours, while an overloaded soubroutine delivers a wider-range behaviours

example of different CALL statements, for an overloaded soubroutine :

1) using at least one variable

- for example, using CALL OSUB V1=1 V2 V3 or CALL OSUB V1=2 V2 V3
- inside OSUB should be a conditional function, that will behave differently, depending on V1 value
- V1 is a "critical argument", since it's value tells the soubroutine how it must behave
- for complex codes, overloading may require at least 2 "critical arguments"

2) using combinations of local variables : one, many, or none

- for example, using CALL OSUB or CALL OSUB ILK = 0
- this approach does not always require the presence of a "critical argument"
- in other words, the overload behaviour is not mainly triggered by the value of a "critical argument", but by it's presence
- the soubroutine will check if the "critical argument" exists, and behave accordingly
- it works only with local variables, since they can be created on demand
- this method is recommended when boolean / on-off / dual state behaviours are desired
- also local variables names are more suggestive then common variable, making the code easier to read


overloading does not deliver quicker execution times, thus it is not there to shave seconds, but only for code grammar

---

pls check next examples :

dehoting a classic iso-code; this :

    G00 X Y Z
    G01 X Y feed
    G02 X Y R
    G03 X Y R

may be replaced with this :

    X Y Z RR
    X Y feed
    X Y RC
    X Y RT

call o**** ILK = whatever

i like to use ILK like a programmable interlock inside a soubroutine, so to skip some safety checks, and output a particular motion

other examples when i use overload :
... when computing shortest path for C axis, so to handle C_actual_position for codes with or without compensation
... for CZ milling, so to toogle between linear & arch interpolation
... for turret indexing with low clearance, under certain conditions
... for recording absolute or relative time, in time-log soubroutines

kindly

[he1957]

Humm, not quite sure what your driving at. The things I'd say to be careful of in most coding is to be very careful about the behaviour of differing implementations. For example, global variables being global retail their values so that if they have a value and you refer to them in a subroutine call but do not provide a value the results may be unexpected. The same can be said for local variables, one should not assume that any implementation guarantees a variable will be initialised on entry or reference. If a variables storage space is assigned dynamically and is not initialised it may contain a previous value which could cause unexpected results. Also, if a variable (argument, parameter or value) defines some function within a subroutine then the subroutine entry shoud validate what's been passed such that if an erroneous value is passed and not recognised nothing should "fall-through"; either raise an exception (error or flag) and exit/return and/or do nothing.

These behaviours can be difficult and time consuming to debug.

[deadlykitten]

hello he1957 yup, such things require a bit of extra-caution

soubroutines involves nesting levels, and is good to keep an evidence, so to be sure that a variable designed for a specific nesting level won't manifest into another

osp for mills behaves differently then osp for lathes, so i try to target the "common ground" for both of them

i keep track of all soubroutines and local variables, so to avoid possible conflicts caused by identical names

i also try to keep the names variations as minimal as possible : as a result, i may use local variables with identical names in different soubroutines, as long as there is no refference between them

These behaviours can be difficult and time consuming to debug

such codes i develop in time, one new file for each code variant, so to easy spot the difference between actual and former code

even if differences between 2 variants are minor, they sum up, and some latest codes may look different from a classical g-code

i hope that one day i will be using the osp somewhere close to it's full potential

it is not difficult when you know what to do ( or at least i like to believe so ), but it is time consuming patience, etc ...

such things i develop&test during long setups, that are there for a while; in the end, when it works, some of them may became default also for short-setups

If a variables storage space is assigned dynamically and is not initialised it may contain a previous value which could cause unexpected results

on the osp, closest thing to it, would be using a local variable without initializing it before ( the EMPTY case )

initializations are direct, not through an intermediate assignment between the variable and the storage field; is not possible to say that variable X has a value of Y that is at located at storage space Z; i guess it would be too much for the osp, but actually i wonder if the osp automatically releases the storage space after a local variable is no longer used

i believe that the osp actually always uses a same amount of storage, that may be filled entirely or partially, depending on the program that is loaded inside it

i don't look into this, but into keeping the system load as minimal as possible, so not to increase the execution time of the program; if i use a soubroutine, regardless of its size, it must behave fast

kindly