Thanks for the replies. I relaize it is the driver, however I can read the serial data using a terminal just fine. So it is something I am doing wrong with labview and the driver that is causing the BSOD. I will keep trouble shooting, and thanks again for you quick replies.
Do you call the driver from multiple locations in your code? In the LabVIEW help look at DLL's, "calling from LabVIEW".
Your driver may work ok in instances where it isn't being accessed from multiple threads, and fail where it does. If you look at the actual "Call Library Function Node" if it is pale yellow in color it has been configured to run in any thread, if dark yellow/orange, only in the UI thread. Unfortunately, changing this setting doesn't make the dll actually able to run in any thread, it has to be written that way. As I described in the long thread I referenced earlier, a driver (supplied by the DAQ hardware company, Not NI, and not chosen by me) was set to run multithreaded, but hadn't actually been written properly to. As I was working at a very large company at that time I had enough pull to get to talk to their (DAQ card company) program, who admitted that his dll was just a wrapper around a lower level USB dll from the USB chip's manufacturer. I ended up dumping the "high level driver" and making calls directly to the USB dll, which was correctly created to run as multi-threaded. Fixed problems. If the dll isn't "run in any thread" it might still operate ok, under limited circumstances.
Now while your's might not be the same, dll's created by smaller "no name" companies are immediately suspect. I cringe everytime I start a new project with hardware I've not encountered before when I'm told it "comes with LabVIEW drivers". Too often these seem to have been created by the summer engineering intern!
Good Luck! Keep us in the loop!
I would try a different usb-serial. I struggled with a converter that didnt work and it is not worth it. I have had vary good luck with easySync devices for both 232 and 485. Most of these talk continiously in industrial environments 24-7 never with a blue screen.
Just my opinion, I would rather spend <$100 than charge several hours of my time for a problem like this (could be unresolvable since the driver is fixed and will most likely always crash).
As for it working in terminal, are you testing this over a continious time period since your crashes are periodic and semi random?
Well I am not calling a .dll that I am aware of. I am reading it using VISA serial read. I just also realized that the issue started when I intrduced a sequence around all of my program. I was having an issue where I was creating a file to save to, but as I was putting the info in, the while loop was starting, therefore my data was not starting at 0. Can't see how this would cause an issue, but maybe it is trying to call the VISA read more than once, which causes the BSOD. Is there another method where I can delay my while loop starting ie: only starts once I have set up the save file info. Thanks again for all your help.
After re-reading you post I see you are using a Teensy (I assume development board) and communicating serial via Visa. Your error post shows the crash in the dll, this could be a driver bug or a non thread safe dll called in parallel. You can enforce that the calls are not done in parallel by wrapping the call in non reentrant calls. You can work with the developer of the driver and see if you can get a fix or a way to avoid the crash, but I still think the queue is very unlikely the source of the crash. Hard to tell without looking at the code.
Thanks, I will contact them. One interesting aspect is the fact if I run the 'advanced serial write and read.vi', it has no issues at all, only when I run my code with the queues. Why would these cause an issue with the driver? I can attach my code, as long as you don't judge the mess of lines I have. But the basics of my program are, I read values as a wheel spins, and each 10 deg I get a serial print out with values that I then build arrays with since I want to collect information for each 10deg and each revolution. I then use these arrays to do further calculations. My next step is to use the queues, but strip my code down to the very basics and see if that helps. Thanks again for all the help. If I do post my code, how do I submit it will all the subvi's included? Thanks again for your help.
If you can attach your code, it might help us, and we won't beat you up Too much about style. 😉 You will probably get some "constructive criticism".
Well here is my minimal code. I just had it running for over 10 minutes and then bluescreen. However just running advance serial.vi, it has no issues at all. Why would adding simple queue mess it up? Originally I had everything in one loop, but when I would try to save the data, so each 10deg, it would miss data ie: I would get position 0, 20, 40, 70 etc...which is not good, but my build array sub vi's would not miss this data. Plus from all my readings, they say to use the producer consumer since it will help the system run better and not miss any data. So, if I run the Teensy and read the serial in a terminal it runs fine, if I run the advance serial VI it runs ok, if I add a queue BSOD. Let me know if need anything else.
Well with more testing I think I have a working system. I still have to let it run for +2hrs, but it ran for more than 10 minutes without issues. I found an old post where someone had a similar issue, and they fixed it by using a property node to indicate how many bytes are at the serial port to then determine the # of bytes to read. Knock on wood this will work, but so far so good, and if this is the reason why, then I am going to be pissed that it was such an easy solution.
It's good that it is looking like things are working for you. But using Bytes at Port isn't the solution. It is either just a coincidence, or the underlying driver for this serial port has other problems that it just shouldn't have.