Internet PLC Forum

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.

I haven't found a great answer for editing PC6 files.

The exported custom functions are exported using what I'd call UNIX end of line format. I have found editors that can cope with the end of line problems.  Simple windows editors like NotePad can't deal with the exported format.

To get the edited text back into the PC6 program I cut and paste between my text editor window and the iTriLog custom function editor window.

I also use the "find" and "find all" stuff in the custom function editor as a crude search and replace mechanism.

I wish I had a better answer,

Gary d

I'm sorry, but I can not help you.

I think that your coding style has limited your options.

You might consider throwing more hardware at the problem.  Add another PLC to manage the display.  

I know that this adds extra cost to your project but if you can't change your coding style then a second PLC gives you the opportunity to manage the display of messages independently of the execution of your test sequence.

Gary d

I've attached a "zipped" version of the test code described in the previous post.

Gary D.

OK.

Perhaps this approach might meet your needs:

1. You have a loop of code that executes a sequence of 50 tests.
2. This loop of code runs continuously from test 1..50 and just repeats, forever.
3. For each test there is a RELAY that is set/cleared based on the success/failure of that test.  If no test fail then no RELAYs are set.

If you have 1..3 working, then you just need a method to display
a message for each failure (RELAY bit that is set).  The message for each failure is to be displayed for 5 seconds.

Is this close?

I do have a few questions about how you have structured this code that performs 50 test:
1.  Do all of the tests execute on a single scan of the ladder logic?
2.  If the tests are distributed across multiple scans of the ladder
     logic do any of the tests use the DELAY statement?

Depending on how your code is structured, I may have a simple solution to your problem.

Gary D.

I'm sorry, but I do not understand the problem that you are trying to solve.

Can you explain what you are trying to achieve?

I understand that you are trying to test 50 different things.

Do you test all 50 things, save the results and then display messages only for those tests that failed?

Are all of your tests pass/fail?

Gary d

You can and should do the delay in ladder logic.

If the only job for your custom function is to display error messages, then you could call the custom function periodically.  If it takes 5 seconds for a human to read a message, then call your message display function once ever 5 seconds.


Gary d

Let me clarify the issue with the Custom Function names.  What is happening is that changes made to the I/O table list of custom functions is not being correctly propagated to the list of custom functions that is shown within the custom function editor.  

I'm guessing that your code maintains multiple lists of custom functions names and that all instances of this list are not being maintained.

I have attached a ".pdf" file with screen shots that demonstrate how to reproduce this problem.  This problem exists with Java 1.4.2_19 and the recent Java 7.0.90.5.

On my attempts to copy using <ctrl>-C from the I/O Table.  The "blue" cursor was highlighting the label name.  In this mode the right-click only gets me the I/O shift up/down options.  If instead I select the RELAY name for edit, then highlight the name and then right-click a different menu opens and this menu has the copy option.  I think that my problem with this was mostly my own operator error problem.  


Best regards,

Gary D.