labview architecture

[MoReese]

Down convert to 8.5 so others can take a look.

[samiti]

Hello MoReese, all,

i saved my vi on 8.0 version,

hope you don't mind taking a look at it,

Best regards,

[MoReese]

Well, first your VI is way too busy.  Consider using sub-VIs to clean up your block diagram.  Make the Producer/Consumer loops your main structurs in your main VI.  Everything else can be tucked away neatly into sub-VIs.

You have at least 3 loops that are infinite.  You need a mechanism for breaking out of these loops.  Try to aviod using local variables.  For instance, your config loop for VISA only needs to run through once.  You can wire a boolean constant to the stop terminal here, in which case you may not even need a loop at this point, unless you want to break out when a certain condition exists, such as receiving a specific character.  What is the purpose of having two Stop buttons?  You only need one and this should only be present during development, but that's up to you on how much control you want the operator to have.  I don't know that you need all these Notifiers?  You may be able to achieve the desired results by only using the queue from the Producer/Consumer loop.  Monitor the incoming data from the serial port and compare the header portion of the frame.  Use this as the trigger to receive the frame, this should put out a boolean that can go to a case structure that contains the Enqueue Element function, which will then pass the request to the Consumer loop.  From there you can receive the data.

[samiti]

Hello Reese, all

in fact i have 4 infinite loops

-the first loop is the producer loop : its cheks continuously if there is a byte at port if yes it notifies the consumer loop

-the second loop is the consumer loop : it continue taking bytes read from the producer and checks if there is a frame under format PDUS+PAYLOAD+PDUE

wher PDUS=header , PDUE=footer ,PAYLOAD=the usefull data, so a state machine do this process and once we have a complete frame we extract the payload

and notify the payload processing loop that there is a payload extracted

-the third loop= payload processing loop takes the payload and cheks if there is an acknowledgment it notifies the write loop to send the next command, and when the baudrate command is sent and the ack has been received we must change visa configure with the new baudrate, ===> this is the big problem: how can i change this baudrate.

the forth loop: is the loop that enables us to send commands to STM32

i've done some changes on my VI according to your advice(Reese's )  it is now so much easier, (i didn't want to put subvis just to let you have a clearer idea on  interaction between loops) i have also elminated notifiers and kept only these :

a notifier to tell apyload processing loop that there is a payload to process on

a notifier to tell the write loop that there is an acknowledgment received so we can send the next command.

i kept visa configure inside while loop because when the baudrate command will be received by stm32 we must change the baudrate( if we keep visa outside the loop there is no way to change its baudrate parameter)

please check out the new VI and i you have other explanations/suggestions/corrections don't hesitate,

Thank you

[MoReese]

A little better, but your loops are still infinite.  If you only want them to run once, depending on their application, the boolean must be true.

Your baudrate can be changed by extracting this information from the received data, performing a string>>numeric conversion (like your doing in case 1) and loading the shift register with the new value.  You don't need the case structure in your Producer loop this way.  Simply wire your shift register to your Visa config VI.  I would init your shift register with the default baud rate (9600?).

One other thing, make your enums typedefs and give them meaningful names instead of just numbers (self-documenting).

[Kira_T]

Hi Samiti,

I would also suggest that you use the Release Queue VI so that you can remove that queue from the memory allocation and release that resource.  This will help you with the performance of LabVIEW and avoid errors. 

Regards,

Kira T

[samiti]

Hello all,

thank you for your advices, i have found a solution for th baudrate updating, i have used a get notifier status which outputs the the last notification: for example initially i have a baudrate=9600 and i haven't sent yet the command to stm32 to change its baudrate to 115200(for example) so this notifier status(which role is to notify the visa configure to changethe baudrate to the new one if an acknowledgment has been received by stm32) has a 0 as output in this case i use the initial baudrate, if there a notification to change the baudrate this notifier will always output the new baudrate(115200 different from 0) in this case(diffrent from zero) the visa baudrate will use this new value,, i have also changed visa write in the same loop as the visa read and visa configure, so it will use the new baudrate to write data to stm32,

i think that using infinite loops for every action allows me to keep reading/writing while processing data so loops work together without being interrupted.

i'll use now subVis to make it clearer/add release queue to avoid errors and make other improvements

i have attached my new Vi. please don't hesitate to comment it.

Best regards,

sami

[MoReese]

---

@samiti wrote:
 

i think that using infinite loops for every action allows me to keep reading/writing while processing data so loops work together without being interrupted.

 

---

It's not a good idea to have an infinite loop because you have no way to completely end your program.  You cannot shut things down properly.  Plus if there is an error, your loop will continue to process with unpredictable results.

[samiti]

Hello reese,

in fact that is my big problem; how not to use these while loops, i didn't find any other idea during months: what i want is to have subvi which continuousely read and write commnds to stm32 without interruption and another subvi which uses data read in the first subvi, even the producer consumer is based on while loops.

how can i solve this problem otherwise??

[MoReese]

Typically your main program/VI is running inside of a while loop, that then executes sub-VIs from there.  The problem is not your while loops, but how they are stopping, which is non-existent in this case.  For any loop, such as your Visa configuration that you only want to execute once, or when a certain condition exists, you don't need a while loop for this.  This should go somewhere inside your producer or consumer loops and be executed at init or when you want to change your baud rate (case structure).  Your program will be more fluidic and modular if you stick with just your Producer/Consumer loops on your top-level.  Your Producer loop should have a Stop button wired to the stop terminal.  Your Consumer loop should stop only on error, which you can wire a true to it from the error case, or you can wire the error cluster to it directly.  I typically do this in the Producer loop as well using the ORing function with the stop button.

But like I said, you probably don't need most of your while loops, these should be made into sub-VIs and stuck in your Producer loop.  This way they will constantly be executed with every iteration (no need for while loops).