01-07-2009 12:45 PM
01-07-2009 01:05 PM
01-07-2009 01:43 PM
I think you'd be better off using an enum to control the cases and casting the counter to your enum (wired to the case selector). You can easily order the elements in your enum any way you need and your code will be a bit easier to read (each state would have a human-readable case name, rather than a number). Make it a type-defined enum and it'll automatically update wherever it's used.
Jim
PS - rearranging the cases will only put case 81 in between 21 and 21; it won't change the order of execution.
01-07-2009 07:33 PM
HarveyG wrote:
I am using a Case structure with a Shift Register wired into the case number and increment this as a counter to create a sequential execution structure. The program starts at case 0 and after this case has completed the shift register increments and calls the next case. I have a program where there are 80 cases and if I need to insert a new one it auto numbers the next case number e.g. 81 even if the new case is inserted in the middle. I then have to manually increment the rest of the cases after it which can take some time. Is there a way to insert a case in the middle, e.g. position 20 and have the rest auto renumber e.g. 21 to 81?
If you happen to figure out an "easy" way to do this please post it. I have been thinking on this and have posted about it before but have not come up with anything that is an easy solution. I also have many cases and frequently add or re-arrange them.
01-07-2009 08:24 PM
ssilk wrote:
I also have many cases and frequently add or re-arrange them.
You really need to evaluate your program design, because code like this is not maintainable and would drive me insane. :o.
Apparently, you don't want to simply re-arrange cases, but it seems you actually want to re-assign the cases to different selector values. This makes no sense to me.
Can you show us a simplified version of your program so we have a better idea what you are actually trying to do.
01-11-2009 12:18 PM
altenbach wrote:
ssilk wrote:
I also have many cases and frequently add or re-arrange them.You really need to evaluate your program design, because code like this is not maintainable and would drive me insane. :o.
Apparently, you don't want to simply re-arrange cases, but it seems you actually want to re-assign the cases to different selector values. This makes no sense to me.
Can you show us a simplified version of your program so we have a better idea what you are actually trying to do.
This is a sample of what my next generation of program is going to resemble. keep in mind that this is only 2 steps in a sequence that is typically 20 or more steps. These include everything from saving the data of the part (serial num, date time, operator #, pertinent test data) to printing a barcode label ad operating a mass flow leaktester via serial control. I currently have all of this running on about 25 test stations in Mexico for about 20 different types of harnesses. I initially programmed these straight out of the basic labview programming course 4 years ago and I have over complicated things and certainly made some poor choices in how I handle variables and I/O functions. Now it is time to develop a new template to use in the future.
What I show in the example is nothing to difficult, however when adding cases to to this seqence it is less than easy. adding to the difficulty is when you add in rework sequences where some steps are skipped or others added using data gathered from operator input or a data file. These determinations will be made by handing off a different number to the sequence shift register. If I decide to add a step in the middle I will need to re-arrange all of the cases to get these in the proper sequntial order then I have to go through and make sure that all of the pointers in the other sequences still point to their proper location. I am also considering running my I/O in a parallel loop so that all I need to do is call a global variable and set the value for it instead of calling an express vi each time.
Although I sound like I am being lazy and maybe a little picky keep in mind that, generally, I develop these programs without ever seeing the fixtures or harnesses involved. Anything that I can do to make this more fool proof will help keep me from flying south of the border to troubleshoot systems and visit with angry customers.
Honduras is not beautiful any time of the year no matter what the tourism board tells you.
01-11-2009 01:12 PM
Hissilk,
you really (really!) should redesign your vis...
1) When attaching a llb it would be nice to mark the main vi or atleast give us the name.
2) Why do you have all those while loops which only run once because of the constant wired to the stop condition? Remove them!
3) You heavily use globals and you have a lot of race conditions in there! Try to minimize the usage of globals. (Try to think more LabView instead of C!)
4) Have you ever heard about the error cluster? You can also use it to set the order of computation and so get rid of this minimalistic state machine...
5) Have you heard about the LV style guide? Wires from left to right, inputs on subvis on the left of the icon, outputs on the right...
And then replace your sequence counter with an enum as mentioned before!
01-11-2009 01:24 PM - edited 01-11-2009 01:24 PM
01-11-2009 02:14 PM
ssilk wrote:
What I show in the example is nothing to difficult, however when adding cases to to this seqence it is less than easy. adding to the difficulty is when you add in rework sequences where some steps are skipped or others added using data gathered from operator input or a data file. These determinations will be made by handing off a different number to the sequence shift register. If I decide to add a step in the middle I will need to re-arrange all of the cases to get these in the proper sequntial order then I have to go through and make sure that all of the pointers in the other sequences still point to their proper location. I am also considering running my I/O in a parallel loop so that all I need to do is call a global variable and set the value for it instead of calling an express vi each time.
See, but your only problem is the fact that you use "+1" in each case instead of a diagram constant (or "select" based on some outcome) that determines the next state.
You really need to make your code more scalable. Right now every change (e.g. in the number of cases") requires other changes (e.g. in the diagram constant that determines when to stop). It would be much simpler to add a TRUE to the last case and wire it out to the stop. Now make the tunnel "use default if unwired" and in will only stop in the last case.
It makes no sense to have the boolean shift register, because none of the states use the previous value. They cannot anyway, because the VI stops when an error occurs! All you need is output a boolean from each state indicating error condition.
Especially with 20+ cases, it would make the code much more readable to use a typedef enum to carry the state information. Here is a very rough draft. If you want more states, simply edit the typedef as shown in the diagram comment.
(I don't have any DAQ hardware, so I did not look at your subVIs).
You might also want to look into using the JKI state machine template. That's some fantastic coding based a lot of experience. Good luck!