Flowcode Support Board

jgu1 wrote: ↑

Sat Oct 11, 2025 9:19 am

UNTIL(RemoteDown == 1 || Endestop_Down == 1)
UNTIL(RemoteDown = 1 OR Endestop_Down = 1)
WHILE(RemoteDown == 0 && Endestop_Down == 0)
UNTIL((RemoteDown == 0) && (Endestop_Down == 0))

And your suggest Martin (RemoteDown == 1) || (Endestop_Down == 1) none of them work

I sense that one of the variables is not being read in FC as soon as there are two variables, bugs?

In these expressions in Flowcode, a single "=" is equivalent to the double equals "==" when comparing values. You can use either, but I am a C/++ programmer and I personally prefer the double equals. The single equals in C/JavaScript/etc is used for assignment, but it is used for comparisons in languages like Basic and Pascal. Flowcode allows either.

For "not equals to" you can use "!=" or "<>".

"OR" is the bitwise operator and is equivalent to the single "|" operator in C. You want to use the logical operator "||" (or "&&" for logical AND).

I'd second the use of brackets. It makes it easier to see the intention of the code.

Another thing to consider when using bytes/ints as essentially boolean is to check that they are zero or not zero rather than a specific value. For example, if a byte value of "RemoteDown" was 2 (for some season) then "IF(RemoteDown == 1)" would be false, even though "IF (RemoteDown)" would be true. For this reason, it's often preferable to do something like "IF (RemoteDown != 0)" which is always true for any non-zero value of RemoteDown.


As for why it's not working in your code, if you are certain it's not a problem with your own code, then there are 2 things I can think it could be. Although both are very unlikely.

1. A compiler optimisation is causing a variable to be set to the wrong value.

2. A hardware fault that means the variable is not being set correctly.

For both of these, you could try putting some check in your code that the variables are actually being set to the values you expect at the appropriate time.

Another thing you could try is something like this:

Is the signal being read correctly - you are just reading a pin for RemoteUp, EndStopUp etc - check that you are getting 0 or 1...

|| and && do work correctly for OR and AND ...

Martin

Hi

Much like Jorgen I had to retro fit to an existing door. Owner had wired up himself using keyswitch but no endstops, so magnetic contacts were used to electrically stop when fully open/ closed via appropriate relays (motor did have an inbuilt cut out if "stuck"). RC was added later in the form of a 2-ch keyfob from cheapo-websites. Keyswitch was retained internally for manual operation as should there be a power cut when operating, when power was restored it would be in an unknown state and therefore would not operate remotely.

The cheapo remote I used, when operated provided relay outputs and worked well enough. If I remember correctly I only used DC.

https://www.amazon.co.uk/dp/B08CRGLWH2? ... in_title_4

Looking at your last chart I see you use an interrupt every 16uS to check for activity and as Viktor commented, everything is ultimately run from within an interrupt. Not sure that would be the best way to achieve. Better to set a "Flag" or such like and process within Main, but anyway, moving on.

I assumed, to follow the chart, that door is closed and you will press Remote Up to open. All variables would be at default as nothing is set yet.

Interrupt triggers and we move to Decision macro
From there we move to Up macro

We test if FlagDown =1 (default is 0 so we move on)
We test if EndStop_Up = 1 (assume it isn't)
We test if FlagUp = 1 (default is 0 so we move on)
We test if RemoteUp = 1 (I assume this is RC input and is operated)
We branch and set FlagUp to 1
We enable Up_On (assume this is motor)
We loop until RemoteUp = 0 (assume RC button released?)
Delay 100mS
Exit

Back in Decision we next move to StopUp macro (with motor running and FlagUp set to 1)

We read EndStop_Up (default is 0)
We read RemoteUp (Should be 0)
We test if FlagUp =1 (yes) && RemoteUp = 1 (possibly) or if EndStop_Up =1
If so we branch and stop motor

If I have read correctly this is where you are running into problems?

I say in the above that RemoteUp = 1 (possibly). That is because I don't know how your remote works. Does it provide a one-shot? Does it provide a pulsed or constant "On" whilst held? Are two pins toggled? Without knowing I can't fully understand what is happening on pins.

Some RC units are very cheap and bounce is horrendous lasting a few hundreds of mS. Perhaps try increasing debounce in the button components and also increasing your delay as you exit Up macro?

As others suggest, it would be a good idea to monitor / confirm pin status. If you have a logic analyser or scope then connect to Input / Outputs to monitor and correlate.

Regards

Hi again all !

Exactly the same remote I have Laim. First thank´s for all the support tips I get from you, by these, I have now found the fault, How stupid is it allow to be, as we said I DK I gues you also have tryed to get "blind" when troubleshooting in a program you have made, and mine, simple fault.

In the end of the sequence where It wait for: RemoteUP = 1 || Endestop_Up = 1 Yes it work, but what I forget is that it leave the loop, turn of the output but emidiately start again in the mainloop and I never see the output go low, because it set on again, that´s why I thought RemoteUP = 1 not work. So I add a loop more and use RemoteUP = 0 || Endestop_Up = 1 (Think you Martin have mentioid) in this loop so when I release the remote it run out in mainloop again, hope you understand.

Imagine, I was accusing FC of bugs I have learn a lot today

Thank you guys, I am happy now, nice weekend.

Br Jorgen

Good news, Jorgen.
One only note: you read the end switch state as byte.
Bool will save you some space (if you plan to extend the program later).