S
Steinhoff
Hello,
In reply to KEJR.
DACHSview-SDL doesn't support SFC ... it supports function block display (as done by other newer standards - e.g. IEC61499). Besides the FBD is also supported a subset of elements of Petri Nets .... used for the lamp ON/OFF example.
The thread concept used for FBD includes blocking/non-blocking threads scheduled by the RTOS. These threads can be assigned to individual cores of multi-core CPUs. That's provides any kind of parallelism.
> You mention your system can develop an outline for overall top level structure using graphical language (lets say SFC), but can you have parallel execution of SFC elements that are coded in text code and happen to contain "blocking" code? <
Yes, blocking function blocks are allowed.
> In the case of automation I'll define blocking as waiting on an external resource such as an input bit from a sensor. i.e. code equivalent to:
> While(Mysensor == OFF); <
Bad example ... waiting could be done on semaphores, mutexes, messages and software/hardware interrupts
> What I'm getting at is that I have seen systems that allow you to define a system structure in SFC, and to have the internals of the SFC blocks consist of a text language (usually Structured text, or ST). The problem with a lot of IEC implementations, especially related to ST code is that the internal ST code must not block or else the system will watchdog. <
Yes, this a one of the most disadvantages of the polling operation of IEC61131-3. Blocking function blocks/calls are not allowed in that environment.
Distributed application are also not allowed.
> Does your system allow parallel execution when one or more of the executing SFC elements are blocking? <
Yes, the threads of the DACHSview target are not scheduled by an internal proprietary co-operative scheduler of the target ... they are scheduled as system processes (or threads) by the RTOS scheduler.
> Is this accomplished via multiple RTOS threads, or do you do the technique of skipping to the next parallel element once a blocking condition is encountered on the current element? <
We are using multiple RTOS threads coded with function blocks. This allows us e.g. to run parallel execution of these threads on different CPU cores ....
We use function block display as a general purpose development language ... without the restrictions of IEC61131-3.
Best Regards
Armin Steinhoff
In reply to KEJR.
DACHSview-SDL doesn't support SFC ... it supports function block display (as done by other newer standards - e.g. IEC61499). Besides the FBD is also supported a subset of elements of Petri Nets .... used for the lamp ON/OFF example.
The thread concept used for FBD includes blocking/non-blocking threads scheduled by the RTOS. These threads can be assigned to individual cores of multi-core CPUs. That's provides any kind of parallelism.
> You mention your system can develop an outline for overall top level structure using graphical language (lets say SFC), but can you have parallel execution of SFC elements that are coded in text code and happen to contain "blocking" code? <
Yes, blocking function blocks are allowed.
> In the case of automation I'll define blocking as waiting on an external resource such as an input bit from a sensor. i.e. code equivalent to:
> While(Mysensor == OFF); <
Bad example ... waiting could be done on semaphores, mutexes, messages and software/hardware interrupts
> What I'm getting at is that I have seen systems that allow you to define a system structure in SFC, and to have the internals of the SFC blocks consist of a text language (usually Structured text, or ST). The problem with a lot of IEC implementations, especially related to ST code is that the internal ST code must not block or else the system will watchdog. <
Yes, this a one of the most disadvantages of the polling operation of IEC61131-3. Blocking function blocks/calls are not allowed in that environment.
Distributed application are also not allowed.
> Does your system allow parallel execution when one or more of the executing SFC elements are blocking? <
Yes, the threads of the DACHSview target are not scheduled by an internal proprietary co-operative scheduler of the target ... they are scheduled as system processes (or threads) by the RTOS scheduler.
> Is this accomplished via multiple RTOS threads, or do you do the technique of skipping to the next parallel element once a blocking condition is encountered on the current element? <
We are using multiple RTOS threads coded with function blocks. This allows us e.g. to run parallel execution of these threads on different CPU cores ....
We use function block display as a general purpose development language ... without the restrictions of IEC61131-3.
Best Regards
Armin Steinhoff