flat squence structure

[rsd3k]

i'm trying to build a labview program for parallel port adc circuit.

following is the procudeure i want use.

Frame 1:-

Data = inport(Read_Port); /* Read the digital data */

Data = Data AND 0xF0; /* Get Higher Nibble */

Data = Data EOR 0x80;

Frame 2:-

out_data = out_data OR Data_Parallel_Low; /* Get Lower Nibble */

outportb(Channel_Port,out_data);

Frame 3:- temp = inport(Read_Port); read the parallel port for lower nibble

temp = (temp & 0xF0 );

temp = temp ^ 0x80 ;

temp = temp >> 4 ;

Data = Data | temp;

i'm thinking of saving the result in the 1st frame into a variable and use it in

the 3rd frame .

Just wondering is this the correct method.If so how can save

the out put of the OR gate in to a variable

pls find the attached VI

thanks,

Download File:post-6124-1160836794.vi

[Doon]

Just wondering is this the correct method.If so how can save

the out put of the OR gate in to a variable

pls find the attached VI

thanks,

Hiya rsd3k,

Firstly, you can create a local vairable in LabVIEW. Simply create an indicator at the output of your eXOR gate. Then right-click the indicator terminal and select Create>Local Variable.

However, I have been taught that it is better to use data-path precidence than using sequence structures. As I understand, every one of those little squares between frames results in a new data instance (i.e., a new memory alocation). I would do away with the frames, altogether, and use the error path to establish order. That is, connect the error out of the first sub-vi to the error in of the next, and so on. LabVIEW only executes a sub-vi when all of its input lines have data.

hope that helps

[Yair]

As I understand, every one of those little squares between frames results in a new data instance (i.e., a new memory alocation)

I can't see the code, but I would like to point out that tunnels do not automatically cause data copies. LV optimizes the usage of memory and only makes a copy if the data is needed in more than one place.

Using dataflow instead of a sequence is better, just not for that specific reason.

[Mike Ashe]

Rules of (Data) Acquisition #334: "Thou Shalt Not Sequence"

Or there will be consequences ...

Couldn' resist that one, the coffee is great this morning.

[peteski]

Rules of (Data) Acquisition #334: "Thou Shalt Not Sequence"

Or there will be consequences ...

Couldn' resist that one, the coffee is great this morning.

I do agree that heavy dependence on sequence structures is a big "no-no" in good LabView design, especially in light of using state machines instead, but I must admit to using them occasionally to force a chain of events without resorting to making a subvi to force it explicitly. For instance:

Essentially, through trial and error I had found that the Stanford Research TIU620 seemed to need a 3 ms wait between the write and the read for this vi to work properly, and this was a quick and simple way to do it. I could have made a small vi as well to do the same thing, but didn't bother to. I find using the "box" of the sequence structure to force some data dependencies convenient, particularly at the end of execution of multiple parallel loops, where I want to make sure all the loops have cleanly exited before commencing with the next step.

Just my :2cents: !

-Pete Liiva

[crelf]

I do agree that heavy dependence on sequence structures is a big "no-no" in good LabView design, especially in light of using state machines instead, but I must admit to using them occasionally to force a chain of events without resorting to making a subvi to force it explicitly.

In summary, sequences should only be used to force dataflow (not sequencing, but dataflow).

[peteski]

In summary, sequences should only be used to force dataflow (not sequencing, but dataflow).

Yes, I can definately agree to that! Although, in my weaker moments...

-Pete Liiva

[Ton Plomp]

Hi Peteski,

what about this:

I love these OpenG thingies more every day!!!

Ton

[Neville D]

Essentially, through trial and error I had found that the Stanford Research TIU620 seemed to need a 3 ms wait between the write and the read for this vi to work properly, and this was a quick and simple way to do it. I could have made a small vi as well to do the same thing, but didn't bother to. I find using the "box" of the sequence structure to force some data dependencies convenient, particularly at the end of execution of multiple parallel loops, where I want to make sure all the loops have cleanly exited before commencing with the next step.

Just my :2cents: !

-Pete Liiva

Peter,

If you use the OpenG toolkits, they have a wait VI with error clusters. VERRRY useful.

Downloading and installing the OpenG toolkits is a real breeze thanks to the latest VI Package Manager.

Neville.

[peteski]

Peter,

If you use the OpenG toolkits, they have a wait VI with error clusters. VERRRY useful.

Downloading and installing the OpenG toolkits is a real breeze thanks to the latest VI Package Manager.

Neville.

Neville and Ton,

Thanks, I had looked at the OpenG toolkits in the past once or twice, though recently I haven't installed them in the project that I'm presently "embedded" in. I may be remembering incorrectly, but it seemed that it was easiest to install OpenG if you had a direct link to the internet, and often our developmental lab computers are specifically left OFF of the internet, for a variety of reasons.

BTW, the example code I "snipped out" was from some older code I had from Labview 5.1.1, well before I had heard of OpenG. It was the quickest and easiest example I could think of to illustrate my point.

I'll have to look into installing OpenG toolkits on one of my connected machines and see what makes sense in the long run for the machines off of the internet.

Best regards,

-Pete Liiva

[Chris Davis]

Neville and Ton,

Thanks, I had looked at the OpenG toolkits in the past once or twice, though recently I haven't installed them in the project that I'm presently "embedded" in. I may be remembering incorrectly, but it seemed that it was easiest to install OpenG if you had a direct link to the internet, and often our developmental lab computers are specifically left OFF of the internet, for a variety of reasons.

BTW, the example code I "snipped out" was from some older code I had from Labview 5.1.1, well before I had heard of OpenG. It was the quickest and easiest example I could think of to illustrate my point.

I'll have to look into installing OpenG toolkits on one of my connected machines and see what makes sense in the long run for the machines off of the internet.

Best regards,

-Pete Liiva

I'm in the same situation. I've found that there is a (fairly) easy way to move OpenG Packages to off-line computers. Simply copy the "cache" directory of commander or VIPM to a keyfob. You can then add these packages and install them as you need to.

BTW, this topic came up in the beta stage of VIPM, and JKI has stated that they are working on an easier way to move the packages to non-Internet computers.

[peteski]

I'm in the same situation. I've found that there is a (fairly) easy way to move OpenG Packages to off-line computers. Simply copy the "cache" directory of commander or VIPM to a keyfob. You can then add these packages and install them as you need to.

BTW, this topic came up in the beta stage of VIPM, and JKI has stated that they are working on an easier way to move the packages to non-Internet computers.

:thumbup: Cool! I may look into this shortly. This could come in very handy!

Thanks,

-Pete Liiva

[LAVA 1.0 Content]

If you use the OpenG toolkits, they have a wait VI with error clusters. VERRRY useful.

I'm a fan of the OpenG toolkit too, but don't forget that there has been a way to do this since 7.1 using the Time Delay and Elapsed Time "Express VIs" ( Did I say that?!)

They look bad on your diagram when placed, but you can right-click and select "view as icon" to make them less obtrusive... Just a thought when you get stuck somewhere without "OpenG on a stick"

There's a thought for the prize of a coding challenge; a nice sized USB stick drive (>=2GB) preloaded with OpenG tools and everything in the Code Repository...

[Neville D]

I'm a fan of the OpenG toolkit too, but don't forget that there has been a way to do this since 7.1 using the Time Delay and Elapsed Time "Express VIs" ( Did I say that?!)

They look bad on your diagram when placed, but you can right-click and select "view as icon" to make them less obtrusive... Just a thought when you get stuck somewhere without "OpenG on a stick"

There's a thought for the prize of a coding challenge; a nice sized USB stick drive (>=2GB) preloaded with OpenG tools and everything in the Code Repository...

Another secret place for a Wait.vi with error chaining is:

Traditional DAQ Pallet >Counters>Intermediate>Wait+ ms.vi (or something like that).. It even has an additional time input in seconds

Unfortunately, by default Traditional DAQ no longer gets installed when installing the newer versions, and I have only LV 8.2 on my PC at the moment.

Neville.

[Mike Ashe]

In summary, sequences should only be used to force dataflow (not sequencing, but dataflow).

Yes, I can definately agree to that! Although, in my weaker moments...

-Pete Liiva

Rules are made to be followed, until you decide to break them. The important thing is to know them and know when to break them. I use them to inforce dataflow when all else fails and then occasionally just for decorative purposes to separate code items. (But that is very seldom).