Over the years you have been adding things to i_TRiLOGI to improve the functionality and to improve the readability of the PLC code.
I really like the #define (pre-processor) mechanism, a lot.
Since you added the ability to shift I/O names up/down in the I/O Tables this has had the unintended side effect of breaking code.
The access to Counter/Timer Set Values and Present Values can only support an integer constants or variables for the argument n:
GetTimerSV(n)
SetCtrSV(n)
TimerPV[n]
GetCtrSV(n)
SetCtrSV[n]
CtrPV[n]
It would be very nice if the "name" of the COUNTER or TIMER that is used in the I/O Table could be used in place of "n". The TBASIC parser (tokenizer) allows both integer constants as well as integer variables for the argument "n".
This way if you wrote code that had a COUNTER named "EventCtr" that was physical counter #10 in the I/O table then you could access the present value of this counter in a custom function with code like this:
A = CtrPV[EventCtr]
rather than like this:
A = CtrPV[10]
I think that this would be pretty simple for your parser to handle. You are generating a symbol table that relates names to I/O #'s because you can handle statements like:
If TestIO(EventCtr) ... where EventCtr is a name in the I/O of a COUNTER. The TBASIC parser (tokenizer) will accept integer constants, integer variables and symbols used in the I/O table as the argument "n". See it can be done!!!
Because you have added the ability to shift I/O Table elements up/down it is very easy to break any custom function that uses
A = CtrPV[10]
If it could be written as
A = CtrPV[EventCtr] then the I/O shift would not break the code. There is also a possibility that the code may be a bit easier to understand and maintain.
Part of what made me think of this is that I am working with your example program, "ExtendedFileSystem.PC6". The custom function, ConnFTP, has code that accesses the PV of TIMER #2. This timer is not defined in the I/O table. It is not obvious by looking at the I/O Table that this TIMER is being used at all. It is equally mysterious when looking at this code with on-line monitoring when a TIMER with out a name wakes up and runs through values. I do 100% understand what the custom is using TIMER #2 to accomplish.
Best Regards,
Gary D.
