Array display in front panel slows down when scrolling

[q-bertsuit]

Sorry about that, when you have been staring at something for so long you forget that other people haven't.

The computer has two cores, I tried to install the drivers for the serial card on a 4 core computer with windows 7, but the drivers for the serial card doesn't work.

I'm using a SIO4 card from General Standards.http://www.generalstandards.com/view-products2.php?BD_family=sio4b. The sensor I'm reading from uses SDLC protocol and sends 400 * 28byte packages per second (11,4k bytes). The FIFO on the card is 512 bytes. The card takes care of all the low level stuff, so I just have to call the read VI often enough to get out the data.

The stacked sequence is very similar to what you will find in this demo from the vendor http://www.generalstandards.com/downloads/gsc_sio4b_bx_sync_labview_v1.2.9.zip

It's just opening a connection with the card, setting the protocol and some registers.

The two sub VI's contain dlls, so I don't know what's in them. They were made by the vendor.

The upper while loop waits up 5 seconds (or rather the VI in the loop does) for a package to be ready in the card FIFOs. If data is ready it returns with the data immediately.

I understand it's difficult to debug without knowing what's in the VI's, but from what I can understand, it must be that the FIFOs on the card are to small. I guess scrolling the mouse wheel uses a lot of CPU time. Or at least more than 44ms.

Thanks again

[Ben]

dll calls will run in the User Interface thread by default. So check to see how the dll calls are configured(right-click the node on the diagram).

If they aren't running in tht UI thread forget me.

Ben

[q-bertsuit]

Yes, the dll is run in UI thread. Should I change this to "any thread" ?

[Ben]

Only if the dll was developed to be thread-safe.

You will have to check wiht the developer of the dll to find that answer.

I believe it was rolf Kalbermatter who posted years ago, that if the dll is not thread-safe and you call it other threads, it MAY work right up until your app crashes.

Ben

[altenbach]

---

@q-bertsuit wrote:

Yes, the dll is run in UI thread. Should I change this to "any thread" ?

---

Wow, I was suspecting that this is your problem, but I was waiting for you to tell us that their "driver" is using a third party DLL. I've looked at the example program from general standards and it is absolutely deplorable.

The sad part is that they don't even know how to spell LabVIEW on their download page! This alone makes me very suspicious.

The example VI is horrible. Looking at the revision number we are on revision 431. Looks like this driver started in the last century and they probably had some random summer intern straight from high school and without much formal LabVIEW training have a stab at it, with other interns making revisions over the years.

Notable observations:

1. None of the subVIs have any kind of error handling (While not absolutely needed, it is useful to establish execution order without the need of sequence structures).
2. blatant overuse of sequences.
3. The big stacked sequence is very poor programming style
4. The flat sequence inside frame #7 makes no sense. The code would run identically without it.
5. OTOH, in some frames (e.g. frame 2 ..6) subVIs are called in parallel and all that protects them is their non-reentrant nature.
6. The case structure in "outer frame 8, inner frame 2" is the silliest thing I've seen in a long time.
7. Same place: The logic to stop the inner loop is straight from Rube Goldberg.
8. The use of local variables to relay the RX and TX data between frames causes additional copies in memory and is absolutely not needed. Very poor programming style!
9. The code is just peppered with data type mismatches and coercions. There are so many red coercion dots that it looks like it has the measles. 😞
10. Why is "board number" a new diagram constant with every call the the subVIs. This is a maintenenance nightmare. There should be exactly one constant outside the main code wired to all places where it is needed. If you would ever need to change it in the current example code, You would need to change it in dozens of places and accidentally missing one would cause hard to find errors. (maybe it should even be a control with a reasonable default value of 1).
11. Why complicate the logic to stop the inner loop by using logic AND and several inversions?
12. How many times do you need to determine if RXChan=TXChan (frames 1, 5, 6). Once outside the structure should be enough!
13. ...i could go on and on....

Chances are that the dll itself was written by a much better programmer (who knows???) and is is possible that it is safe to call in other threads. Don't change anything before checking with them, though. I would recommend to contact General Standards to see if the dll is safe. Point them to this discussion here! 😄

(For a similarly careless configuration example of third party drivers, the LabVIEW drivers for Phidgets are incorrectly using the UI thread configuration of the call, probably just because it is the LabVIEW default, even though the dll is claimed to be much more robust (see also)).

(On a side note, did you copy over the llb to the correct place as instructed in the readme file?

Quote: This zip archive also includes an updated LabView library, GscApiLabView.llb that includes some

fixes that were causing occassional program crashes. After installation, replace the GscApiLabView.llb
in the %PROGRAMFILES%\General Standards Corporation\GscApiLabView\SIO4B directory with the one in
this zip archive dated 2011/03/15.)

[q-bertsuit]

Being a novice LabVIEW programmer, I didn't really question the demo program at first, I just thought to my self that it would have been poor style in other programming languages. Especially point 10 on your list is a real give away that this hasn't been thought trough. From one of the emails I sent with General Standars I got a hint that this isn't really a priority for them:

 "Chances are, that driver is too old to work on Windows 7.  We don't have very many customers using the serial card with LabView but the ones who do seem to be working fine.  If you change the code to simply log to memory rather than a file, do you still see this problem when you move the mouse, etc?  Just running the sample code here (that only saves to memory), I can't duplicate the problem."

I'm under the impression that the dll's are made by a better programmer. You can find their APIs and some C code examples on their page as well, and they all seem pretty solid.

Yes, I copied the new llb, but there are still some crashes here and there. Very often when you close the program there will be a crash and often a minor change in the code will make it crash when executed.

I was offered a loaner board with much bigger FIFO's to see if it fixes the problem. I will except their offer, but it would still be nice to do everything properly. Even if it fixes the problem, there are still a lot of redundancy in the code and other problems that you have pointed out, that would need to be fixed anyway.

I'll talk to them bout the dll's tomorrow or Monday, and let you know what they say. Thank you again for taking the time to look in to all of this, much appreciated!