increment not incrementing

[Yamaeda]

"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

[DominicRoberton]

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

[altenbach]

---

@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.

[DominicRoberton]

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

[altenbach]

---

@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. 

[DominicRoberton]

"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

[RavensFan]

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!

[altenbach]

---

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.

[DominicRoberton]

"Now that is quite a profound statement!"

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!!

[DominicRoberton]

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