I would like to write input, before execution the application. How to handle this issue?

[A123]

Hi!

I have some challanges when handling input values from front panel which are going to be used in the next step to build command lines to the serial device. Is there a cleaver way to handle this issue? My problem is that the program uses the default values before I get the chance to update new input values.

A

[Dennis_Knutson]

Your program should be written so that it only sends commands when you tell it to. You don't even mention which language you are using but I'll assume it is LabVIEW. If that's the case, your front panel does not have to contain any default vaules unless you set them and proper design (i.e. an event structure) would give you more control. Post the program you've written if you want some specific details.

[A123]

Hi again!

The program is written in Labview. The scope of the program is to set some configuration values.  First the user write input and then the input is used in the command line sent to the RS232 device. I have tried to make an event structure were the input values only are true if value changes with no luck ( probably I have done this the wrong way).  It seems to me that I may split the program in two, first write input and secondly read output. I tried to avoid splitting the program since I was favorizing using local variables.

I will attach the program as soon as I can monday morning.



A

[A123]

Hello,

Here is my VI.

I probably should have put the string operation where I built the command line in the event structure for each variable? And for each mouse leave or value change the command will be sent to the device? 

A

[Albert.Geven]

Hi

The instrument part is layed out quite well, could be better.
In this style with error wires moving from left to right you also determine execution order.
So if you connect one of the outputs of your first sequence frame with the next sequence frame (after the init serial e.g.)
then this will execute in that order.

A wait of 50000 ms (and even a wait on multiple that shows badly enough in almost all ni examples)
is nonsens. LabVIEW will start running all parallell systems at almost the same time.

The best is to encapsulate also the init serial in the seq frame if you really want to wait for user input before you do anything.

The nice fact that labview can execute code in parallel is hurting you.

PS if you have error in error out sequencing (sequence by wire is it called) you don't need a sequence frame anymore!

[A123]

Hallo!

After several trails of troubleshooting by getting errors with buffer overflow, I ended up with this simple solution. If you have some tips of a better design of the VI please tell me (as you hintet in your previous reply)!!

Best regards,

A

[A123]

Sorry, this is more a presentable VI.

[Albert.Geven]

Hi
I removed the useless copies of writing a varaible to its own value in the beginning
I removed the calls to write transmitbuffer (also useless)
I lined up the diagram and got rid of a number of useless case statements

And I could gain a lot when all the status updates were not necessary
(almost all sequenceframes except for the wait ms)

Have you ever used subroutines?
I'll build an example from this in next reply
 

[A123]

Wow, your exellent support makes my VI run much faster. My design was messy, I went from 2 VI and global variables into a single VI and locals variables, and I thought locals variables had to be declared in some way. As you can see, I am new to LabVIEW. Using subroutines are elegant and more efficient way of grafical programming, as my skills advance I will handle the subroutines hopefully.

Looking forward to study your subroutine examples. Thanks for all very useful support and hints!

A

[Albert.Geven]

two versions
   autobc3 with subvi's
   autobc4 with reference to status string

you could modify the send subvi so that an array of commands also could be send  (separated by a semicolon) but  I leave that to you.