Poor serial communication speed

[Dennis_Knutson]

I'm surprised that indexing the array takes longer. You might want to turn on the profiler and see what's happening to memory usage. You might want to try a very simple program that's nothing more than a while loop with a write and a read inside, autoindex the array of strings, and see if just blasting through without all of the extra code you have gets you close to the performance you want.

[cvonallmen@kgs.kaba.com]

My software to download via my vi has 21594 lines. Only the process of getting the data in an array takes me 2:44min.! So, this method can't be faster then getting line per line out of a multilinestring.

[Mads]

After sending a line you start polling for the number of bytes at the port every 1 ms, you do a read every time and check for your ack character. You do not really need to run the read and check operation unless the number of bytes function says the required number of bytes is present (is it just one character?)...that will save some time.

If the reply may consist of more than just one character your code is likely to fail as it is now..If you know the length of the reply check that the number of bytes available matches that number. If the length can vary you need to check the number of bytes, wait for some time and then check if it's the same..if it's the same and non-zero you know that the reply has been received (the wait must be just a bit m
ore than the inter-byte time)...then read it and check if it contains the character.

The line picking does not us emuch time, that's OK. Try removing all the timer, data sent etc. code when testing, you can add that later if you see that things work OK without them.

As commented by others you really use locals the wrong way. My guess is that you have experience with textual languages and think of them as variables...they are not. In G the variable is the wire. Almost all the locals you use could and should be replaced by wires or shift-registers. The sequence structures used can be replaced by flow controlled execution, makes it much more readable.

When you run the download, have you checked how many times the read ACK loop actually runs? If there never is a reply the first 20 ms anyway I would just do an inital wait of 20ms after sending the line..prior to starting the check for the ack.

[cvonallmen@kgs.kaba.com]

First: sorry for the messy code, were trying everything to speed up things.

I did as you said earlier (wait until bytes are in buffer, and then read), and removed it again to try and save some time.

I allready removed the timers earlier of course,but it didn't speed up things. (I think the size of the multi-line string is our problem.)

Yes, the ACK loop runs about 5 times.
So the time i loose has to be somewhere else...

Yes i allready fixed the locals.

[Dennis_Knutson]

I duplicated the lines in your example a whole bunch of times and was able to read in 250,000+ lines in under 10 seconds. Try Read From Spreadsheet File modified to return an array of strings. There are instructions inside the VI for doing this.

[cvonallmen@kgs.kaba.com]

Hey, that's much faster! Thanks for the tip.
Before i tried with a loop and replace array subset.

[Mads]

You sent a file earlier, is the real file much bigger?
I did a timing check to see how much time is spent just picking all the lines out and that was pretty fast (it may slow down on a computer with little memory etc..off course). If the file really is much bigger, try reading just a portion of it (e.g. using the read lines function), then send those lines, read a new batch of lines...etc. until all the lines have been sent. That way you'll avoid working on that big a string.

Try stripping down the code to just the part necessary to do the download and start timing things from there...

[cvonallmen@kgs.kaba.com]

The file is 957kb (21594 lines)! but we are working on the same idee: chopping the hole file/string in little handy parts, and then sending them. Looks like that's the biggest benefit in speed till now.