goto command

[uknanoman]

Hi Tech
I am just doing a routine where I need to branch off within a custom function using the goto command. I have a register which holds my Sequence number and is updated
according to other factors in the program. This is named as SeqNo and is assigned to a dm[xx] register. Now everything works fine using multiple ifs and goto @xx but the text can get
very long using either if or an elseif variation.  Anyway I tried to use the following line so as to get rid of all the ifs

Goto @SeqNo

But this gave me an error. So then I tried

a$="@"+chr$(SeqNo)
goto a$         

This did not work either so any help would be appreciated.


These lines below show what I am trying to reduce if possible.

if SeqNo = 1
goto @1
endif

if SeqNo = 2
goto @2
endif

if SeqNo = 3
goto @3
endif

if SeqNo = 10
goto @10  '
endif

@1
code for this routine
EXIT

@2
code for this routine
EXIT

@3
code for this routine
EXIT

@10
code for this routine
EXIT

[garysdickinson]

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

[support]

The destination xxx for GOTO  @xxx is determined at compile time and not at run time. Hence it is not possible to assign it a variable.

Gary is right that structured programming can do away with GOTO altogether, although GOTO sometime can be a quick way to get out from deep inside a nested structure to another location. However, over-using GOTO can easily lead to so called "spaghetti codes" that can be error prone and difficult to debug so should be used sparingly.

[uknanoman]

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

[uknanoman]

Hi support
               Thanks for the clarification, I was typing to Gary whilst this came in so I appreciate the detail so I will now proceed as guided by Gary and the info you have now supplied. My response to Gary includes one new way I shall try.
Many thanks to all
Pete

[garysdickinson]

Pete,

it sounds like you are working on a fairly complex problem.

As you have figured out the TBASIC language does not have any sort of computed GOTO or computed CALL functionality.  So your choices are to either make the computed CALL using a CF or to do it in ladder logic.

I am guessing that your code is using the variable SeqNo to make decisions.  Most of my  non-trivial  PLC  programs work in this manner. 

The PLCs allow you to use COUNTERs 1..8 as "sequencers". The Present Value of these Sequencer/Counters can be tested in ladder logic and the Preset Values can be changed in ladder logic.  When used as Sequencers you are limited to the values of 0..31.

I use this mechanism for many reasons:

• Ladder logic is faster than TBASIC in making these decisions
• The SeqNo is visible for debug both in simulation and on-line monitoring.
• The SeqNo can be changed during debug to force code to run. for debug.
• it provides a method to support multiple threads of operation. Poor-man's multitasking.

This approach scares most PLC programmers because it sounds too complex.

If you are interested, I have posted many examples of this sort of approach.  I’d be happy explain how it works.

Gary d

[uknanoman]

Hi Gary
          Thanks for the response and the offer of help. The system I am working on at the moment is perhaps more busy than complex. And yes I am using the SeqNo as you described and I
am using CF's within which, the last operation of the CF is to update the SeqNo to point to the next appropriate CF, which would be the next operation of the control system. The upshot of all
of this is that I have CFs simply named as Step_01 ~ Step_40 which allows me to quickly locate the Tbasic within that step.  As you rightly mentioned about the inbuilt sequencers, I have used them before on an older version of the same control system using a nano+external HMI. However with this new project I am using a WX100 and because I am introducing new functionality and controlling the inbuilt display at the same time it seemed prudent to incorporate display and control within each CF. So far it is working ok but i did not know that Ladder Logic is faster than Tbasic in making decisions! I shall keep this in mind for future projects where speed is essential. FYI The Current project is a Cement Silo Filling control system, As I said before I have 4 of these working already and this is a sort of replacement / update version for hardware as well as software. The system strictly regulates the filling procedure and tracks the operators procedure doing prechecks and testing of system functionality before during and after the filling. It uses modbus to communicate with a weigh system for silo contents and a remote i/o block at the top of the silo for interfacing to analogue and digital sensors. The system logs events into an event log and sends e-mails on our LAN. One thing I missed on the WX100 is the ethernet port and so I have used a Cheap MANGO wireless Router( less than £20.00) to give me back that facility, so now I have the best of both worlds so that the unit is physically connected by ethernet cable to our LAN for e-mails, spreadsheet interfacing, and remote programming from the office, but for onsite local mods (at the control system) I now don't have to plug my laptop in anymore as I connect by the WIFI.  When I finish the new project unit I will probably upload it to this site as a customer project for viewing the superb capabilities of the TRiPlc products.
Anyway I appreciate you interest and offer of help so I may come to you at some future point or feel free to comment on any of my future posts.
All the Best Peter