Same string display fields in different case?

[Sarah83]

Hi!

I have a new problem.

I have many fields for "string display" and five "combine fields". This five combine fields are for choosing one connection over a radio button. If you choose connection 1 at the combine field you can configure only one COM port. If you choose connection 2 you see two configurations for the COM ports and so on... (for every connection is a LED - green connection OK/red no connection or failure)

Now, i made a case structure for every choice of connection.

My problem, i made the configurations for all five choices. So case one is OK. Now i like to put the configurations for the connection 2 in my 2nd case. but if i copy the configuration for connection 1 from case 1 in case 2 i'll get new fields and LED's (numbered with 6 e.g. string to write 6). But i don't want new fields, i like to use only my five strings for the individual connections. I like to use the same LED's in case 2 as in case 3 , only in case 3 should every string display field, LED etc. be added.

Hmmm, very difficult to explain.... i hope everyone understand

[James McAnanama]

:clock: I am still using LV7.0 & 6.1 - I can't open your vi. Do you mind saving it as 7.0?

File>Save with Options>

Click radio button on left "Save for Previous", then specify LabView Version 7.0 or 6.1.

[Michael Aivaliotis]

I opened the code in LV7.1 and re-saved it in 7.0 for the rest of you.

I am attaching it.

As far as the code itself. I would recommend that you create 1 serial IO VI and reuse that. It will make your code easier to manage and read. Also, try to keep your diagram to a limited space like 1024x768 screen resolution. My desktop is 1680x1050 and I still couldn't fit everything on there. When I get a chance, I will try to submit a revision to your code but in the meantime, maybe others can make some suggestions.

As related to your original question. I think if you create a few sub-vi's as I suggest, you will see that it will solve your problem.

Download File:post-2-1092243301.llb

[Mikrobi]

I opened the code in LV7.1 and re-saved it in 7.0 for the rest of you.

I am attaching it.

As far as the code itself. I would recommend that you create 1 serial IO VI and reuse that. It will make your code easier to manage and read. Also, try to keep your diagram to a limited space like 1024x768 screen resolution. My desktop is 1680x1050 and I still couldn't fit everything on there. When I get a chance, I will try to submit a revision to your code but in the meantime, maybe others can make some suggestions.

As related to your original question. I think if you create a few sub-vi's as I suggest, you will see that it will solve your problem.

1397[/snapback]

First what come upon Sara: suggest to use Tab Controls from Containers Palette.

You will be able to hide repeated parts like Connection 1, 2 and others.

And everything will be within one click

regards

Mikrobi

[Sarah83]

I think if you create a few sub-vi's as I suggest, you will see that it will solve your problem.

1397[/snapback]

But I thought in a sub vi I can only put things that I needn't see permanent on the frontpanel. And I want to see my chosen connections (string to write, bytes written, VISA resource name, read string, bytes read...) and my "display area (visible display strings depends on the chosen connections from the radio button) " (the RX and TX display strings) permanent. Only the configuration should hide everytime until a user is clicking on the "config button".

I see, for a "greenhorn" it's not easy

[Mikrobi]

But I thought in a sub vi I can only put things that I needn't see permanent on the frontpanel. And I want to see my chosen connections (string to write, bytes written, VISA resource name, read string, bytes read...) and my "display area (visible display strings depends on the chosen connections from the radio button) " (the RX and TX display strings) permanent. Only the configuration should hide everytime until a user is clicking on the "config button".

I see, for a "greenhorn" it's not easy   

1413[/snapback]

You could locate all configuration controls in one cluster and set Visible property for them depend state of "config button"

And if you use Tab Control, you can locate controls or indicators for each Connection at different tab and you still will have separate terminals on diagram (it is different to locate controls in cluster). Tab Control allow you set page with Connection you selected by connecting numeric value to Tab Control terminal at the diagram.

No one born adult

regards

Mikrobi

[James McAnanama]

I opened the code in LV7.1 and re-saved it in 7.0 for the rest of you.

I am attaching it.

1397[/snapback]

Thanks Michael.

Sarah,

I agree with Michael - you can simplify your code. I have taken a crack at it (and improved some of my own code at the same time )

From what I interpreted from your code, you are trying to make a serial comms tester. You want the ability to test the transmission (TX) from one comm port to a series of receiving (RX) comm ports. When you run the attached program, it waits for you to specify which comm ports are to be tested in TX, and which comm ports will be tested in RX. Each TX port will try to write to each RX port (i.e. if you specify COMM1 in the TX array, COMM1 and COMM2 in the RX array, then the program will try to write from COMM1 to COMM1 and from COMM1 to COMM2. The results of each test are displayed (see attached .jpg file for screen shot). The actual COMM tests are done using the same sub routine. This subroutine takes the serial settings from an .ini file (ex baud etc).

The purpose of this example is the show programming considerations with abstraction, loose coupling, and good cohesion. (A topic that I am still learning myself, so don't expect perfection! )

If this were an application that I were using, I would go further to move all parametric data to a MySQL database and get rid of the .ini text file. Further, I would add routines to pull "test recipes" from the same MySQL DB - The UI would have a drop down showing the available test recipes, and the user would either select the desired test, or the program would sequence through them. Finally, the test results would be stored back to the DB.

Make sure that the ini file is in the same directory as the .llb.

Cheers, :beer:

James

Download File:post-365-1092325016.llb

[James McAnanama]

Here's the ini file...

OK, never mind... I can't upload an ini. So, you will have to resave this file as SerialParams.ini

Download File:post-365-1092325393.txt

[Sarah83]

  Here's the ini file...

OK, never mind...   I can't upload an ini.  So, you will have to resave this file as SerialParams.ini

1422[/snapback]

Oh, there are many new things for me, first I have to read in the LV help file

But this .vi don't work, the problem must be at "read key (u32).vi ..

[James McAnanama]

hmmm... I am not sure why it doesn't work. Make sure the ini file is saved as SerialParams.ini and not SerialParams.ini.txt and that it is in the same directory as the llb.

[Sarah83]

hmmm...

[James McAnanama]

Okay. The problem is with your ini file - it can't find it or open it. Probe the input to the open config data vi (see attached image). Make sure your ini file has the same path and file name as shown in the probed results.

-> failure 1 at config data registry.vi (get section): invalid object 0 (display parameter is -> invalid - NI488 command needs GPIB controller as active controller)

It amuses me that LabView often blames the GPIB controller for misc errors - even if you have no GPIB devices or code. It is like NI has a great deal of contempt for the GPIB bus! :laugh:

The test still attempts to work, but with default values (that's why you get more errors as it tries to access the ini file, but ultimately runs the test). I should have added some more error handling around the ini access to allow it to fail gracefully. Next time... :clock:

[Sarah83]

Okay.  The problem is with your ini file - it can't find it or open it.  Probe the input to the open config data vi (see attached image).  Make sure your ini file has the same path and file name as shown in the probed results.

OK, now all failure messages disappeared :worship:

It amuses me that LabView often blames the GPIB controller for misc errors - even if you have no GPIB devices or code.  It is like NI has a great deal of contempt for the GPIB bus! :laugh:

1435[/snapback]

[Sarah83]

OK, now all failure messages disappeared  :worship:

1437[/snapback]

ahh I only want to edit my post