LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Program for 20+ sensors. Preliminary design questions.

I wrote a full explanation but it got deleted. My real code is at the lab so I wrote up some temp code to illustrate what I'm doing and focusing on the points I'm worried about. I'll post my actual code with more questions later.

 

I'm installing 20 sensors around a system. All are triggered by 5v TTL signals. I've been learning lab view and working on a program for the last week and a half (so naturally, my real code needs to be cleaned up and I have to remove a lot of my experimentation). And yes, I have been searching the forum. It's what I credit with getting me this far.

 

-I've settled on a producer/consumer design with a queue (or multiple since there will be so many sensors).

- Each sensor has it's own set of global variables (IO port, status, etc) which are used throughout the program (Because I didn't and don't have a full understanding what the overall file structure will look like and I wanted to be able to port data to other VI's without having to alter much code) all in their own frame in the separate stacked sequence so I can duplicate the frame and change the variables when adding a new sensor. (Trying to make N+1 easy to add)

 

 

I followed the idea of Produce -> Process -> Consume.

-The producer loop will focus on reading the data and making sure it's new data (or a miss) before adding it to the queue. I've also placed the shutdown sequence in this loop because It will only run when I want the data to stop.

-The consumer loop will take data from the queue and format it for an excel file. It also contains any ancillary operations that I can't fit into the event structure.

-I'm using the event structure like interrupts in C.

 

Primary Concerns (at this time)

- Have I made an error using a lot of global variables?

- My start up sequence is very slow even though at this time I'm only starting one sensor. The layer cake of case structures and a sequence structure probably contribute to that.

- Is it a mistake to move my startup and shutdown procedures Into my loops and making sure they're controlled by a case structure?

- Should I add a separate loop for ancillary functions?

- Am I building a good base for 20 sensors and possible more equipment?

Temp code pt1.JPG

Temp code pt2.JPG

  

Thank you for your time. Sorry for the long post but I can't stop thinking about this project.


___________________________________________________________________________________________________________________________________________________
Upgraded from intern to undergrad automation engineer. Attempting to explain to my employer why I need official training…. since I’m the groups only automation engineer.
0 Kudos
Message 1 of 16
(386 Views)

Hi garthenar,

 


@garthenar wrote:

I wrote a full explanation but it got deleted. I've been learning lab view 


Maybe because it is your first post in this forum, so it may fall into quarantine before getting released into the open public…

(Btw. when you learn LabVIEW you should learn the correct spelling of LabVIEW, too.)

 


@garthenar wrote:

- Have I made an error using a lot of global variables?

- My start up sequence is very slow even though at this time I'm only starting one sensor. The layer cake of case structures and a sequence structure probably contribute to that.

- Is it a mistake to move my startup and shutdown procedures Into my loops and making sure they're controlled by a case structure?

- Should I add a separate loop for ancillary functions?

- Am I building a good base for 20 sensors and possible more equipment?


  • Using globals is (on its own) not wrong. But using several globals per sensor for 20+ sensors seems wrong to me. What about using a cluster per sensor, to keep the sensor-related settings in a "bounding structure"? What about using an array of clusters to keep settings of all sensors? What about using OOP, to handle one sensor? What about using an array of objects to handle more than one sensor?
  • When you build "layer cakes" of sequences/case structures you should think of statemachines! You need atleast 3 states: init, measurement, de-init. Using this approach you don't need any/several case structures inside the loops, each controlled by one more local/global variable: the statemachine will handle the proper execution flow…
  • Adding one more loop for "ancillary" functions is ok.
  • I don't think you build a "good base" to handle 20+ sensors/equipment. What about (conditional) logging? What about safety checks and emergency actions on your testbench?
Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
Message 2 of 16
(319 Views)

Are you actually using global variables anywhere else or just inside this VI?

 

Because if not you could just use local variables.

Nesting too many case structures is frowned upon, because it's harder to debug.

 

Try attaching your VI, it'll be easier to see what you've already got and how we can advise you.

Message 3 of 16
(316 Views)

You have provided quite nicely some basic information and code. However I'm still a little confused how are you going to interface these 20 sensors? What kind of HW will you use for that? This defines quite a lot for handling the N sensors. Is it NI hardware (cDAQ, cRIO, etc). If something else, how do you interface it, serial port, TCP, etc? Is it one HW interface for all sensors or will you need to interface several HW? If yes, are they all alike or different?

 

Regarding your questions:

There should be no need to use global variables.

There's not really anything in the attached code that would run any visible time. However, you will run into problems, if you try to use property nodes in a loop that runs fast (>10Hz).

Your basic description on the producer - consumer concept seems okay, but I don't really see it in the code yet. 

Any ancillary operations should be fine in consumer.

Regarding cases and loops: in general you usually have something like:

  1. Set up
  2. Run
  3. Clean up

You can set up and clean up implement it before/after your producer loop or you can implement it inside the producer, if you make it a state machine. Both solutions are fine. 

 


 

Primary Concerns (at this time)

- Have I made an error using a lot of global variables?

- My start up sequence is very slow even though at this time I'm only starting one sensor. The layer cake of case structures and a sequence structure probably contribute to that.

- Is it a mistake to move my startup and shutdown procedures Into my loops and making sure they're controlled by a case structure?

- Should I add a separate loop for ancillary functions?

- Am I building a good base for 20 sensors and possible more equipment?

Temp code pt1.JPG

Temp code pt2.JPG

  

Thank you for your time. Sorry for the long post but I can't stop thinking about this project.


 

Message 4 of 16
(313 Views)

@garthenar wrote:

- Have I made an error using a lot of global variables?


Probably. Globals usually are a mistake.

 

There are situations where they are not terrible, maybe even slightly appropriate. I rarely end up with more then 1 or 2 Globals in a 2500+ VIs project. Those are for things that are global by nature. I can't give an example, as they are never needed, really.

 

If you're into OO or libraries, you can make the Globals private. This is much better (or much less bad) than a global. The scope prevents using the global out of the library.

 

Functional Globals can prevent a lot of harm Globals can do (race conditions) but only when designed well. I avoid them as well, as in principle they are just globals.

 

Finally, by reference (DVR) can be used to replace what globals do. They are still by wire, and that makes them less evil. They are terrible to debug though. Probes don't give information, and stopping the main and testing a sub VI becomes impossible.

 

So what to do?

 

Well, ideally, communicate through events or queues. Maybe channel wires.

 

@garthenar wrote:

- My start up sequence is very slow even though at this time I'm only starting one sensor. The layer cake of case structures and a sequence structure probably contribute to that.


Even if you have 50 nested structures, it would take a fraction of a micro second to execute.

 

I doubt that's the timing problem.

 

It is a maintenance problem though. Multi frame structures prevent overview. Event structures are needed, sometimes case structures are too. Sequence structures a never needed, and only used to prevent making things nice (during testing, quick and dirty).  

 

So what makes things slow?

 

Hard to tell without a VI. Property nodes (value property) synchronize with the refresh rate of your screen. That could be it. The wait for multiple shouldn't ideally be needed. Loops should ideally be event driven, hardware driven or waiting for a queue. 

 

@garthenar wrote:

- Is it a mistake to move my startup and shutdown procedures Into my loops and making sure they're controlled by a case structure?

I don't see any problem in that.

 

@garthenar wrote:

- Should I add a separate loop for ancillary functions?


That's hard to answer without a lot of details.

 

My approach would be to have an event loop and parallel loops (either static (preferably) or dynamic), and start occasional ancillary tasks dynamically from the event loop.

 

Again, details are missing here.

 

@garthenar wrote:

- Am I building a good base for 20 sensors and possible more equipment?


Lots of questions here.

 

20 sensors coming from one device? 20 similar sensors? 20 different devices?

 

The timing would be crucial for the design choice. Polling 20 'sensors' once per second allows a much simpler structure than 20 different kHz-GHz signals coming from 20 different devices. The latter requires different parallel loops. They don't need to be dynamic if the setup is fixed.

Message 5 of 16
(287 Views)

Thank you GerdW,

 

I'm replying to everyone here and analyzing their suggestions before I clean up and post my LabVIEW code (likely tonight).

 

In the end I'd love to use a state machine but it's going to take me a bit to figure out how to get it to function. The data is read off a serial port byte by byte. It's what I want by the end of the summer though.

 

I'm adding a loop (with a timer or something to slow it down) for the ancillary processes to keep things out of the way of my producer consumer loops.

 

New Questions

-Any quick advice on (conditional) logging,safety checks, and emergency actions? That's something I've been worried about but to busy learning the basics to really get into. (Naturally I'll be doing some research into it).

 

I've added these items to my list of things to research.

- Clusters

- (Conditional) Logging

- safety checks and emergency actions in labview

- oop in LabVIEW


___________________________________________________________________________________________________________________________________________________
Upgraded from intern to undergrad automation engineer. Attempting to explain to my employer why I need official training…. since I’m the groups only automation engineer.
0 Kudos
Message 6 of 16
(254 Views)

Thank you AeroSoul,

 

I'm replying to everyone here and analyzing their suggestions before I clean up and post my code (likely tonight).

 

I'm not using these variables anywhere else yet but the full scope of the project is not understood. Being inexperienced with the full layout of LabVIEW (Still fuzzy, but doing much better) I opted for global variables in case I would be using multiple VI's.

 

Now, I "think" that if I needed to, I could funnel local variables through globals if I ever needed to use them elsewhere. What are your thoughts on this?

 

Also, my program is all in one LLB. I don't know if that's how it's normally done.

 

Thanks again.


___________________________________________________________________________________________________________________________________________________
Upgraded from intern to undergrad automation engineer. Attempting to explain to my employer why I need official training…. since I’m the groups only automation engineer.
0 Kudos
Message 7 of 16
(226 Views)

Thank you Jamosgee,

 

I'm replying to everyone here and analyzing their suggestions before I clean up and post my code (likely tonight).

 

For your questions.

The 20 sensors are all the same, they hook up in pairs to the same hardware(10 of them) that communicates to the computer via Ethernet using VISA.

 

They all run of of 5v TTL signals. some will be hit at the tame time, others will follow in a sequence. (I'll know more as we get farther along).

 

Note: At this point in time I can get data reliable from the one sensor and it's hardware. Tomorrow I begin testing to make sure I can get proper data from the system with it's TTL.

 

Note 2: I want to expand this program to handle more than just the sensors eventually. I want to get information from out scopes using VISA and add stepper motors for controlling the system. BUT that is way on the back burner.

 

I'll definitely be more specific in my next post.

 

Regarding your answers to my questions

- I'm definitely going to be looking at replacing my global variables. I'll do that while learning more about apps / projects with labview

- I've added a loop to run at less than 10 hz for my UI property nodes.

- Setup, Run, Clean up. Sounds good. I've been trying to make sure I don't have "loose data" in my program or left on my serial port but I've been considering adding more code to make sure of that at startup.

 

Thank you again.


___________________________________________________________________________________________________________________________________________________
Upgraded from intern to undergrad automation engineer. Attempting to explain to my employer why I need official training…. since I’m the groups only automation engineer.
Message 8 of 16
(223 Views)

Thank you ,

 

I'm replying to everyone here and analyzing their suggestions before I clean up and post my code (likely tonight).

Also, I'll be trying to quote your post so this may look a little weird until I edit it.

 



Probably. Globals usually are a mistake.

 


Works for me. I'll do some more research into how they work and start replacing them after I have some other critical functionality implemented. (After alpha maybe?)

 


If you're into OO or libraries, you can make the Globals private. This is much better (or much less bad) than a global. The scope prevents using the global out of the library.

 

Functional Globals can prevent a lot of harm Globals can do (race conditions) but only when designed well. I avoid them as well, as in principle they are just globals.


- My first language was Java so I have some experience with OOP and It's on my research list for LabView.

- I'm currently writing my program in an LLB. I don't know how proper that is but it let me keep everything together and from what I can tell, lock others out of my code. I'm the only one here with any real programming experience (even though this is only my second real programming project) and I need to make sure they keep their hands off the code.

- I'm staying away from Functional Globals for now since I'm trying to get a handle on some of the basics still but they're on the list of things to learn.

 


Well, ideally, communicate through events or queues. Maybe channel wires.

- I'll look up channel wires. That sounds like it might be good. I originally used a lot of variables because I come from a C background and didn't know about LabVIEW's "data flow" build. Also I didn't want wire spaghetti with 20+ sensors.

 



There's more I want to type but their cleaning the lab and kicking me out of the building so this will have to be it. I'm adding answers to more questions in my next post. With my code in it.

 

Thank you again.


___________________________________________________________________________________________________________________________________________________
Upgraded from intern to undergrad automation engineer. Attempting to explain to my employer why I need official training…. since I’m the groups only automation engineer.
Message 9 of 16
(214 Views)

Hi garthenar,

 


@garthenar wrote:

In the end I'd love to use a state machine but it's going to take me a bit to figure out how to get it to function. The data is read off a serial port byte by byte. It's what I want by the end of the summer though.


LabVIEW comes with a huge library of example VIs and a lot of example projects in the "New…" dialog (file menu). There also are example projects explaining statemachines…

Usually you don't read serial ports "byte by byte"! You should read full messages…

 


@garthenar wrote:

I've added these items to my list of things to research.

- Clusters

- (Conditional) Logging

- safety checks and emergency actions in labview

- oop in LabVIEW


Those "conditional logging" and "safety/emergency" notes were just examples on how to improve your testbench software in the future. They are no (premade) part of LabVIEW, you have to implement that on your own…

 


@garthenar wrote:

I could funnel local variables through globals if I ever needed to use them elsewhere. What are your thoughts on this?

 

Also, my program is all in one LLB. I don't know if that's how it's normally done.


"Funneling locals through globals" doesn't make it better, it's heading the opposite direction!

 

"LLBs" are (old) "LabVIEW libraries": they aren't recommended since 10+ years. You should organize your LabVIEW project using a "LabVIEW project" (lvproj file)! (You know those Training resources in the header of the LabVIEW board to learn the LabVIEW basics?)

 


@garthenar wrote:

I'm currently writing my program in an LLB. I don't know how proper that is but it let me keep everything together and from what I can tell, lock others out of my code. I'm the only one here with any real programming experience (even though this is only my second real programming project) and I need to make sure they keep their hands off the code.


Well, they keep code in one file, but: when there is a file error you lose ALL the files. Better use a LabVIEW project with all related files in a folder (and probably some subfolders). An LLB does NOT lock out others from accessing the included items. (You may use passwords to protect LabVIEW files but those encryption isn't very strong…)

When you have trouble with other people messing with your code you really should setup some SSC tool (SourceCodeControl). This will help you to keep track of your code and all changes made to it…

Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
0 Kudos
Message 10 of 16
(190 Views)