LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

increment not incrementing

"Previous Number From File" - In file v3 it didn't have any initialization, maybe i looked at the wrong file. 🙂

 

I'm glad you got it to work.

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 11 of 20
(456 Views)

No worries,

 

I actually found that the issues seems to be with my cRIO program, after a while it seems to stop assigning the correct numbers to the data.

 

But I'll open another thread about that!!!!

 

I'll post up the final vi that I used for anyone that is interested, it's quite different!  But that is mainly to allow it to run at a sensible speed and not to write HUGE TDMS files.

 

Dom

0 Kudos
Message 12 of 20
(454 Views)

@DominicRoberton wrote:

That is a fair point, I have now converted the U32's to I32's as soon as they are pulled out of the array.



Just glancing at your code, there are many problems. All your loops in the upper part should be FOR loops and not while loops, right?

 

You are still coercing the counter to SGL, which has only a 23 bit mantissa and is thus insufficient to represent consecutive integers in the range you need. You also need to change the representations in the cluster and indicators. As a first step, make sure there are no red coercion dots.


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 13 of 20
(431 Views)

Hi Altenbach,

 

I've been away for a bit and only just had a chance to look at your comments.

 

Will using a For Loop rather than a While Loop be quicker?

 

Also, I couldn't find where the coercion takes place, are you looking at the file titled Read Data and Assess v3.vi?  I only ask because one of the things I did for this version was try and correct all of the coerced points.

 

Cheers for your help,

 

Dom

0 Kudos
Message 14 of 20
(392 Views)

@DominicRoberton wrote:

Will using a For Loop rather than a While Loop be quicker?


When iterating over an array of known size, an autoindexing FOR loop is the correct structure. It eliminates the constant comparison for the termination condition and also eliminates "index array" wired to [i]. Just autoindex at the input tunnel. Still, it won't be much faster. Why is there a 1ms wait in the loop? That will slow you down. 😉

You might also want to remove all these indicators in the innermost loop. Constantly updating the front panel uses resources too.

 

The entire code still looks overly complicated and unreasonable. Why would you make a queue size of 2G??? (If each element is a cluster of a I32 and a longish string, the I32 portions would already occupy 8GB). I would also strongly recomment to treat paths and files as path datatypes, not strings. 


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 15 of 20
(370 Views)

"I would also strongly recomment to treat paths and files as path datatypes, not strings."

 

Why?  I understand that a string uses quite a lot of processor resources, but the list folder vi returns the files in the folder as an array of strings.  I could convert at this point I guess, but I don't understand how that would be hugely beneficial over converting the strings individually before processing.  Would doing a batch conversion be any faster?

 

"Why is there a 1ms wait in the loop?"

 

I was seeing if I could speed the whole thing up by slowing down the two loops, it didn't make any difference!!

 

I had the indicators there purely so I could monitor when the loops were slowing down.  Once I am happy everything is working correctly they will go.

 

Cheers for your help,

 

I have got so much to learn!

 

Dom

0 Kudos
Message 16 of 20
(356 Views)
Using paths will eliminate many problems you could have when you try to build a path using string functions.  Issues like separators in the path (slash vs. backslash) being different on different operating systems are handled automatically by the path building and stripping functions, but using string functions to do that could cause problems in your VI. 

 

 


DominicRoberton wrote:

 

  

I was seeing if I could speed the whole thing up by slowing down the two loops, it didn't make any difference!!



Now that is quite a profound statement!Smiley Very Happy

0 Kudos
Message 17 of 20
(347 Views)

DominicRoberton wrote:

Why?  I understand that a string uses quite a lot of processor resources, but the list folder vi returns the files in the folder as an array of strings.  I could convert at this point I guess, but I don't understand how that would be hugely beneficial over converting the strings individually before processing.  Would doing a batch conversion be any faster?


As Ravens already hinted, paths have different syntax on different OS. If you use strings, your code will immediately break on any other OS. A path is a hierarchical collection of strings, so each part (folder name, file name, etc.) is a string. "List folder" gives you a list of file names, which are strings. You operate on paths using "strip path" and "build path", appending or stripping new elements (strings!) from an existing path. This offers a lot of protection, because LabVIEW will guarantee that the path will be sane and you don't need to worry about OS specific delimiters and such.


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
0 Kudos
Message 18 of 20
(338 Views)

"Now that is quite a profound statement!:smileyvery-happy:"

 

Yeah, it's one of those things I thought I should try!!!

 

I was wondering if one loop was using all the resources so thought forcing the loop to stop might allow the other loops more access and therefor speed up the overall process!!!

 

It made sense in my head!! Smiley Happy

0 Kudos
Message 19 of 20
(320 Views)

Ok,

 

That makes sense.  I very much doubt I will be writing programs to operate across operating systems at this stage.  I shall do it anyway for completeness' sake.

 

You mentioned in an earlier post the code seemed excessive and complicated....  Obviously there are many different ways to achieve the same thing, but considering I will be dealing with anything up to 14GB data sets in 5MB chunks, I would like the code to be as efficient as possible.

 

Cheers.

 

Dom

0 Kudos
Message 20 of 20
(319 Views)