PureBasic Forums - English

Hello,

For my new 'PLC' program, i have a lot of condition code ...
I'm looking for a correct way to exit a [condition]
is a [GOTO] allowed to exit a [IF] or [SELECT] condition ?
is the [Break] command only for [For ... Next] loop ?
I use this method in 68K ASM/BASIC but do it works with PB ?


OS: win 10
PB: 5.73 LTS x64


Q1)
Is this correct way ?
(this as a very simply example)


Q2)
Same question for a [Select] condition ?
thanks again,
Marc

If you always return to LabelA it's better to use a loop with Repeat - Forever (like Until, but without checking)
Break - exit from the cycle

@Sergey

Thanks for your help,
but this was a example code, so it is not always the situation.




And I know 'RTFM'

- I found this about [SELECT] in the documentation ...

Syntax

Goto <label>

Description

This command is used to transfer the program directly to the labels position.
Be cautious when using this function, as incorrect use could cause a program to crash...

Note: To exit a loop safely, you always must use Break instead of Goto,
and never use it inside a Select/EndSelect block (Unless you have the ability to manage the stack yourself, correctly.)

- And about the use of an [GOSUB] I found the use of 'FakeReturn'


- But i did n't found about IF condition ...

Marc

There is no problems with "If" and a "Goto" inside. However usually there is no reason to use "Goto" at all. There are better ways to do what you want, for example Procedures.

There is no need to use goto or gosub and there are several good reasons not to do so. You can nearly always rewrite the code another way and I'd strongly recommend getting into the habit of doing so. The only time you'll see a goto in any of my programs is "OnErrorGoto". This is true of any language I've used for the last 25 years at least.

1) Goto translates to a JMP instruction. JMP is used heavily by the compiler internally to construct logic patterns of all kinds (if/then/else, select/case/default, repeat/until, while/wend). The compiler manages all of these carefully and reliably but humans can't be trusted to do so with the same degree of reliability. If you use goto you stand a chance of breaking the compiler's code somewhere along the line unintentionally, in addition to breaking your own code, if you make a mistake. This means extra work for you in bugs to fix and they can be quite hard to trace sometimes.
2) It adds redundant JMP instructions to the object code. This means wasted processor cycles, which in turn means wasted energy. The more iterations the more the waste. Waste means heat.
3) Using gosub is just making the management of parameters difficult for yourself and asking for extra bugs.
4) Tools like the Callstack aren't goto/gosub aware (because there's no clearly defined parameter list). You render it less useful or even completely useless for your projects. You're giving up a very powerful debugging tool.

Use procedures when you genuinely need to break out a section of code into a separate, reusable, parameterized or self contained thing. If you wish to break out sections of code for your own ease of coding use an include file or a macro. This way the redundant jumping is factored out a single time at compile time by the compiler automatically rather than incurred every time during runtime.

@NicTheQuick
thanks for your answer, that was the answer I was looking for.




@spikey

Thanks for your very interesting comment.
I understand your reasons.

But ...

My original PLC programs are older assembler programs for the MC68000 and MC68HC11E1 microprocessors.
As I use a lot of JMP (jump)=GOTO and JSR (Jump to subroutine)=GOSUB commands in these assembler programs,
and I like to translate them to PB as close as possible (I know these programs works well).

Once these translated programs in PB works well, then I can modernize these and upgrade them to PB.


respecting your comments,
Marc,

marc_256 wrote: Fri Dec 01, 2023 5:09 pmMy original PLC programs are older assembler programs for the MC68000 and MC68HC11E1 microprocessors.
As I use a lot of JMP (jump)=GOTO and JSR (Jump to subroutine)=GOSUB commands in these assembler programs,
and I like to translate them to PB as close as possible (I know these programs works well).

Once these translated programs in PB works well, then I can modernize these and upgrade them to PB.

In my opinion that's a valid reason to work like you just do.
Come back later if you want to modernize it.

I attended a brief training course on Mitsubishi PLC products in the distant past and I can vouch for Marc's comments on very liberal use of goto. It was like using early languages.

Marc, have you thought about writing your own interpreter in PB, for the existing assembler code, so you can just run the code that you already have?

I would think that's achievable. Nice to use the code without rewriting it.

Hi,

I just translated my first (very small program),
and YES it works very well with lots of [IF]s and [GOTO]s.
Wait to see the next step, for the big programs.


@oso

Marc, have you thought about writing your own interpreter in PB, for the existing assembler code, so you can just run the code that you already have?

Well this is in the big plan.
I'm building a 5 axis CNC machine, and the dream is from within my CAD, CAM, CNC program
also have control over my pneumatic valves/pistons via a PLC programs.

And yes, the plan was to write a 68000 assembler code interpreter.
So I can use all my existing programs without converting them to PB code
and a graphical user interface to add/change code.

BUT, first steps first ...


greetings,
marc

And a first screenshot of the 68000 Assembler editor ...



I replaced also the old markers for Dec, Bin, Hex
to d'value, b'value and h'value what is much easier to understand.


Marc

marc_256 wrote: Sat Dec 02, 2023 12:40 am

Marc, have you thought about writing your own interpreter in PB, for the existing assembler code, so you can just run the code that you already have?

Well this is in the big plan. I'm building a 5 axis CNC machine, and the dream is from within my CAD, CAM, CNC program
also have control over my pneumatic valves/pistons via a PLC programs.

It sounds extremely interesting Marc. What type of device is used to enable the desktop computer to control external equipment in that way? Is it a card that you can install in a PC for instance?

And yes, the plan was to write a 68000 assembler code interpreter. So I can use all my existing programs without converting them to PB code and a graphical user interface to add/change code.

Is the screenshot running on a PC? So it is a 68000 emulator? The Motorola 68000 was popular in many minicomputer environments that I used to work on.

Hi oso,

The big plan ...

What type of device is used to enable the desktop computer to control external equipment in that way? Is it a card that you can install in a PC for instance?

I purchast some USB to RS485 and UART to RS485 converters.
So in the RS485 (max. 32 points) environment there are PC laptop, PC desktop, SBC PC (CNC) with TouchScreen 1920x1200 px,
and more arduino DUE and Teensy 4.1 boards.
One of the Teensy 4.1 boards is used to convert GCode to Steppers to drive the CNC machine.
Why Teensy, well they are very small and have FloatingPoint (32 and 64 bits) on board.
All digital IO, analog IO and PWM IO go via the arduino DUE boards.
Even small (GLCD 320x480 px) local displays are connected via DUE and Teensy boards.

So, the main PC is a laptop with PB software who controls all the boards via RS485.
So all data will be visualized on the screen of the MAIN PC in real time.

Also the CNC, pneumatic board and parts of the security boards.

Is the screenshot running on a PC? So it is a 68000 emulator?

Yes, all the software will be on PC and PB ... CAD/CAM/CNC/PLC.

This is the big dream project ...


Marc

It sounds like a very serious project then with a lot of hardware involved. Please keep us updated, it's good to know PB is featuring in this. Your Motorola code is more complex than I'd realised, because the Mitsubishi PLCs that I remember, provided only quite a simple logic set, conditional tests, registers, inputs and outputs, hence suggesting that an interpreter could be written relatively easily.

oso,

Your Motorola code is more complex than I'd realised, because the Mitsubishi PLCs that I remember, provided only quite a simple logic set, conditional tests, registers, inputs and outputs, hence suggesting that an interpreter could be written relatively easily.

This is not the PLC code, this is only a small 68000 assembler code to test my editor.

Please keep us updated

Then it will be better to open a post in the application part of the forum...


Marc