Internet PLC Forum

Hi Gary
          Thanks for the helpful response. Yes I understand your approach and it was a way I originally considered and the reason I was looking for a more simplified textual layout was because within the code sections there are / would be, many more nested ifs. In my example I only showed if branches for 1,2,3 and 10 but in reality there will be about 35 - 40 branches. So my thinking was that by using the goto command I would achieve two things. Firstly all the multiple if / elif / elseif chain would be reduced to one simple line that just reads - goto @xx where xx represents the sequence number. Secondly all the code for each section would then be headed with a @xx and this in my mind grouped in simple chunks of text, each sequentially following the other until coming to the last ‘@40’ label. I realise you get this as I have always been impressed with your many posts over the years so I am really only explaining this in more detail for others who may be wondering what an why I am wittering on about. As so often happens, the process of posting a tech question makes one re-evaluate ones thought process. With this in mind it may be better for me to call up say 40 custom functions from the if elseif chain and segregate my code by custom function rather than by a goto label. Any thoughts ?
Once again thanks for your help
All the best
Pete

I have been writing code for the TRI PLCs for nearly 20 years and have not found a use for the GOTO statement.

I would use the following coding structure for your code:

if SeqNo = 1
    ' code for SeqNo 1
elif SeqNo = 2
    ' code for SeqNo 2
elif SeqNo = 3
    ' code for SeqNo 3
elif SeqNo = 10
    ' code for SeqNo 10
else
    ' code if the SeqNo is not not 1,2,3, or 10 ...
endif

I think that this approach is easier to read and maintain.  Note that "elif" is identical to "elseif" keyword. I just like the shorter version.

Regards,

Gary Dickinson

The LED flashes if there are current flowing through it but it does not mean that the input is recognized by the CPU. 

Are you able to measure the output from the vision system before you connect to the PLC's digital inputs? That way you can be sure what is the output voltage like when the output is ON and OFF.

Remember that the input to E10-Relay+ must be PNP type (i.e. between 18 to 24VDC when ON and 0-3V when OFF) so the output from the vision system must be compatible with the input requirement of the PLC for the CPU to recognize it.

Hi Gary,

Thank you so much for the report and for posting the new V1.13 update of your Simple Menu software that you so kindly shared with other users.

Yes there were some changes to the file format when TL75 was evolving in order to keep compatibility with older .PC6 and .PC7 files. We received a report from a user who had included comma into the "value" field and when it was opened by the older TL74 or TL75, the text after the comma was erroneously parsed out into the "Comment" column and therefore the program couldn't compile properly. We have already fixed that issue and the current TL75 will be able to correctly import the older .PC6 and .PC7 files that may have used comma in the "Value" column. but in the process we had to change the file format to also properly support the new "Comment" column.

We will definitely include your updated V1.13 into the next release of i-TRiLOGI 7.52 that are closed to being released.  The new i-TRiLOGI 7.52 version is going to support HTTP and HTTPS client commands in addition to MQTT client functions that can be fully executed directly on the simulator.  The existing Wx100 user can obtain the full functionality with a simple firmware upgrade. We will keep you informed via email and also display on the info pane at the bottom half of the Custom Function Editor when it is fully released.

 

A long time back I worked with the pre-production Wx100 product using any of a number of versions i-TRiLOGI that were test builds.

I got an email from a Wx100 user and he was having problems with compiling a Wx100 program that I wrote.

The affected file is named "Wx100 Simple Menu V1_12.PC7.

The problem is that this demo code was written with an early version of i-TRiLOGI when the "Comment" field was added to the #define mechanism.  The current tool set V7.5 Build 14 uses a different field separator in the .PC7 file than was used by the early version that I wrote the code with...

The early version used commas as field separators in the PC7 file. Sort of like this:  #,Defined Name,Value,Comment
The current tool set uses commas and an ASCII <RS> (record separator). Looks like this: #,Defined Name,Value<RS>Comment

The problem is that my "old" code when compiled with current tools doesn't recognize the "," before the Comment field so the Value field ends up with the correct "Value" a comma and then the Comment text.  The Comment field is always empty.

I was able to fix the problem for the user, by exporting the #Define Table to a text file and replacing the first "," character by an ASCII TAB character and then importing the edited #Define table back into the PC7 program.  The edited #define table now works perfectly and if I peek into the PC7 file I see the <RS> character in the correct spot.

I have attached the corrected .PC7 file.  It is now named "Wx100 Simple Menu V1_13.PC7.  The only changes from the V1_12 file is the corrected #define and I added a comment for the V1.13 version to give a hint as to why it was changed.

I think that the V1.12 version may appear in in the Wx_Specifics directory and in a Zipped file named "Wx100 Simple Menu.  Is this something that you can fix in a future release?

Best regards,

Gary Dickinson