News:

  • October 13, 2025, 05:22:12 AM

Login with username, password and session length

Author Topic: Feedback wanted: Instantiable programs concept  (Read 34777 times)

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3761
    • Host Engineering
Re: Feedback wanted: Instantiable programs concept
« Reply #60 on: April 27, 2022, 08:35:26 AM »
Is Pythagorean defined within a normal MATH instruction or would it be defined in its own type of function Code-Block?

No, it's not currently defined.

That is an example of MATH Function YOU could write and use.  (Those dang Host people didn't provide a Pythagorean function?  Well, I'll just write my own, thank you  ;D).

RBPLC

  • Hero Member
  • *****
  • Posts: 585
Re: Feedback wanted: Instantiable programs concept
« Reply #61 on: April 27, 2022, 09:17:47 AM »
Is Pythagorean defined within a normal MATH instruction or would it be defined in its own type of function Code-Block?

No, it's not currently defined.

That is an example of MATH Function YOU could write and use.  (Those dang Host people didn't provide a Pythagorean function?  Well, I'll just write my own, thank you  ;D).

I know Pythagorean is not a current function. That's not what I'm asking. I'm asking how a user defined function will actually be created. I'm asking if the user defined function will be created inside of a MATH instruction or if it will be created in its own Code-Block called "Function".

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3761
    • Host Engineering
Re: Feedback wanted: Instantiable programs concept
« Reply #62 on: April 27, 2022, 09:51:35 AM »
I know Pythagorean is not a current function. That's not what I'm asking. I'm asking how a user defined function will actually be created. I'm asking if the user defined function will be created inside of a MATH instruction or if it will be created in its own Code-Block called "Function".

They will be code-blocks.  We currently have 3 different code-block types, PROGRAMs, TASKs, SUBROUTINEs.  You will be able to create FUNCTIONs, USER BOXes, and OBJECTs.  These new ones may or may not be part of a Library mechanism - we'll see.

So, after you create the FUNCTION Pythagorean, you would open up that code-block, write the code.  So then it will be accessible just like SIN, SQRT in all your MATH boxes, and most likely across all your projects, not just the one project you created it in (i.e. the source logic will be in a Library facility).

If your question then is, the Pythagorean code block will be IMPLEMENTED using a MATH box in it, e.g. SQRT(P1**2 + P2**2), could you technically recursively call it.  Yes, just like current Subroutines are recursive, Functions could be recursive.  For example, a lazy but optimized evaluation of Fibonacci values, i.e. see if you've already evaluated Fib of P1, if so, return that value, if not then return P1 + Fib(P1-1).

RBPLC

  • Hero Member
  • *****
  • Posts: 585
Re: Feedback wanted: Instantiable programs concept
« Reply #63 on: April 27, 2022, 09:57:02 AM »
I know Pythagorean is not a current function. That's not what I'm asking. I'm asking how a user defined function will actually be created. I'm asking if the user defined function will be created inside of a MATH instruction or if it will be created in its own Code-Block called "Function".

They will be code-blocks.  We currently have 3 different code-block types, PROGRAMs, TASKs, SUBROUTINEs.  You will be able to create FUNCTIONs, USER BOXes, and OBJECTs.  These new ones may or may not be part of a Library mechanism - we'll see.

So, after you create the FUNCTION Pythagorean, you would open up that code-block, write the code.  So then it will be accessible just like SIN, SQRT in all your MATH boxes, and most likely across all your projects, not just the one project you created it in (i.e. the source logic will be in a Library facility).

If your question then is, the Pythagorean code block will be IMPLEMENTED using a MATH box in it, e.g. SQRT(P1**2 + P2**2), could you technically recursively call it.  Yes, just like current Subroutines are recursive, Functions could be recursive.  For example, a lazy but optimized evaluation of Fibonacci values, i.e. see if you've already evaluated Fib of P1, if so, return that value, if not then return P1 + Fib(P1-1).

This is what I was after. New Code-Blocks where FUNCTIONs are Implemented using a MATH box.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3761
    • Host Engineering
Re: Feedback wanted: Instantiable programs concept
« Reply #64 on: April 27, 2022, 10:18:15 AM »
This is what I was after. New Code-Blocks where FUNCTIONs are Implemented using a MATH box.

It doesn't necessarily have to have a MATH box in the implementation.  It could be a bunch of ladder logic to resolve some boolean expression, or INCs or LERPs or very complex IF/THEN/ELSE that is better implemented as Ladder Logic, not a bunch of nested IF(IF(IF(... type expressions in the calling MATH box.

As long as the value returned is a bit or numeric, and there are no asynchronous instructions, anything goes.  It's just a code-block with a RETURN VALUE at the end (similar to Subroutines requiring RET at the end).

A specific MultiDimensionalArray (MDA) function could be written that you could then do
R[MDA(D10, D21, D7)] in the calling MATH function, where MDA is hard coded for a 3 dimensional array the size [5][10][40] of 2000 R's occupying R1000 through R2999.  So MDA would be a MATH of returning the straight array index of the 3D coordinates P1, P2, P3 as 1000+(P1*10*40)+(P2*40)+P3.  [ 0][1][2] (i.e. MCA(0,1,2)) would return the R index of 1000+(0*10*40)+(1*40)+2 or 1042.  [4][9][39] (i.e. MCA(4,9,39), the highest index of each dimension) would return 1000+(4*10*40)+(9*40)+39 or 2999.  This is basic C multi-dimensional array arithmetic for accessing linear memory (all flat multi-dimensional memory is linear at the processor level).

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3601
  • Darth Ladder
Re: Feedback wanted: Instantiable programs concept
« Reply #65 on: April 27, 2022, 11:04:08 AM »
:o Didn't think of that!
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

RBPLC

  • Hero Member
  • *****
  • Posts: 585
Re: Feedback wanted: Instantiable programs concept
« Reply #66 on: April 28, 2022, 08:32:59 AM »

It doesn't necessarily have to have a MATH box in the implementation.
[/quote]

How is the Function called? Does it have to be called within a MATH box or can it be called like other built-in functions on its own ladder rung? 

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6126
  • Yes Pinky, Do-more will control the world!
Re: Feedback wanted: Instantiable programs concept
« Reply #67 on: April 28, 2022, 08:34:44 AM »
How is the Function called? Does it have to be called within a MATH box or can it be called like other built-in functions on its own ladder rung?

We'd like to have both.
« Last Edit: April 28, 2022, 08:37:10 AM by BobO »
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3761
    • Host Engineering
Re: Feedback wanted: Instantiable programs concept
« Reply #68 on: April 28, 2022, 08:49:34 AM »
How is the Function called? Does it have to be called within a MATH box or can it be called like other built-in functions on its own ladder rung?

MATH Functions, by definition, are only usable in MATH boxes.

User Boxes are what you are probably calling "built-in functions" that are boxes on its own ladder rung.

Here are the terms that I defined earlier in this thread to help with our discussion
https://forum.hosteng.com/index.php?topic=3401.msg27501#msg27501


Function Blocks, Function Block Diagrams, Functions, Math Functions - each of those have different meaning in various languages, hence why I tried to scope out the difference between MATH Functions, User Boxes, and Objects so that everyone can be on the same page.

RBPLC

  • Hero Member
  • *****
  • Posts: 585
Re: Feedback wanted: Instantiable programs concept
« Reply #69 on: May 04, 2022, 03:24:37 PM »
I know Pythagorean is not a current function. That's not what I'm asking. I'm asking how a user defined function will actually be created. I'm asking if the user defined function will be created inside of a MATH instruction or if it will be created in its own Code-Block called "Function".

They will be code-blocks.  We currently have 3 different code-block types, PROGRAMs, TASKs, SUBROUTINEs.  You will be able to create FUNCTIONs, USER BOXes, and OBJECTs.  These new ones may or may not be part of a Library mechanism - we'll see.

So, after you create the FUNCTION Pythagorean, you would open up that code-block, write the code.  So then it will be accessible just like SIN, SQRT in all your MATH boxes, and most likely across all your projects, not just the one project you created it in (i.e. the source logic will be in a Library facility).


If at all possible, the Library mechanism needs to be a thing. One of the most frustrating aspects of using the BRX currently {for my typical use case), is trying to establish a code base that can be reused between projects. Without local/global variables, importing portions of code from other projects is tedious because of potentially re-used variables. Trying to establish a code base requires a great deal of pre-planning or a lot of clean up work on the back end. Without a library mechanism, I see this being the same issue for these new features. From an end user perspective, I would like to be able write one of these new features once and have it saved in a code base where I can easily pull it into a new project with no fuss. I don't want to have to manually export UDTs, re-import them into the current project etc. to get one of these new features to work in another project. Without a library, these features will be useful but only limitedly so. 

rlp122

  • Sr. Member
  • ****
  • Posts: 89
Re: Feedback wanted: Instantiable programs concept
« Reply #70 on: May 08, 2022, 09:24:09 PM »
Going to be starting a new job in about a week as the sole EE.  I am going to try to talk the new job into using BRX instead of the slightly cheaper PLC that they had talked about in my interviews.  Copy/Paste and doing imports is a clunky workaround, but it is a workaround.  I know I would like the library to exist, to be able to have the add-on functionality of the two 800 pound PLC gorilla's would be an amazing time-saver.

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3601
  • Darth Ladder
Re: Feedback wanted: Instantiable programs concept
« Reply #71 on: May 08, 2022, 09:31:16 PM »
If by the two 800 lb PLC gorillas you mean AB and Siemens, I don't think I'd put them in the same group.   Siemens' library facility is vastly superior to what I've used with AB (though admittedly it's been a while).
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

rlp122

  • Sr. Member
  • ****
  • Posts: 89
Re: Feedback wanted: Instantiable programs concept
« Reply #72 on: May 08, 2022, 09:41:57 PM »
If by the two 800 lb PLC gorillas you mean AB and Siemens, I don't think I'd put them in the same group.   Siemens' library facility is vastly superior to what I've used with AB (though admittedly it's been a while).

I dislike both which is why I want one that is done right and gets the BRX closer to the same functionality.  It's a lot easier to knock over the competition when there aren't any strawman arguments about, "There's no Add-ons", "I don't have local variables", "It doesn't do EIP Implicit.", etc, etc.  I know this stuff takes a while to develop and I'm willing to wait. 

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3601
  • Darth Ladder
Re: Feedback wanted: Instantiable programs concept
« Reply #73 on: May 09, 2022, 01:36:48 AM »
What's not to like about Siemens?  I think it's excellent.  With BRX, those are my top two go to platforms.
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.