My Labview program is very big and complicated. It crashed while I am working on development, Fortunately it is restored when restarted.It happens a couple of times a week. I am glad that it does not crash while running.
When crashed, it automatically ask to report to NI. I did it many times, but no response from NI. It just forced to quit; no way to investigate. I don't understand the nature of the crash.
I s'pose you can type cast the resulting array back to the type def'd one.
/Y
I don't think typecasting is working.
I have used I32 and the result is coming in negative. But probe output is a positive value.
You could also try the Coerce To Type function.
But out of pure curiosity, why do you need the reference number?
wrote: If you suspect the offending code is the user "Wait on ..." then toss it temporarily and wait 2-3 the crash interval. If it stops crashing we know what the "problem is". If it still crashes then we have to look elsewhere.
I've disabled it again after altenbach's tip didn't work out, and i'll report back again if it crashes, but I'm not expecting it to. The clock's ticking, at least.
The next step would run just that "special" code on another machine and wait for it to crash. If it does not crash, then the problem may be an interaction issue ... which takes us in yet another direction.
Sadly I don't have the privilege of another machine on which to try this.
That prompts the question "what else was changed" since when it worked. Did the LV version or OS version change?
Still smells like a hardware (related ) issue and not a LV issue.
No other changes, no new hardware. As i mentioned before this was an isolated change. It's just a little thing I've been meaning to do for a while that I had "the spare 5 minutes" this would take to implement. 😑 ha ha
Hi Rang,
wrote: It crashed while I am working on development, Fortunately it is restored when restarted.
I hope you are using any kind of SCC tool to keep a history of your code instead of relying on code restoring capabilities of NI/LabVIEW crash detector?
Hi crossrulz,
I am unable to find the coerce to Type Function .I am using labVIEW 15.
LabVIEW crashing does not in itself indicate that there is a bug in LabVIEW. It is possible to write code that can crash any environment.
Try to break the code into smaller pieces and projects and work on them without loading everything at once and see if that helps. Then you can start tracking down the cause.
Try to remember when the crash started to happen and checkout a version from your SCC before that and see if that crashes too.
Update LabVIEW to the latest SP.
Try on another PC and see if the issue is the same.
Is there anything saved in %UserProfile%\Documents\LabVIEW Data\LVInternalReports\LabVIEW\<lv-version> or in %UserProfile%\DocumentsLabVIEW Data\lvfailurelog?
See here how to capture a crash if LabVIEW doesn't record it.
I'm sure there are lots of threads how to investigate a crash. Search for them too.
This interrupt stuff is getting rather over my head, but wouldn't that also count for Wait On FP Activity? Wouldn't that be handled by an interrupt (reacting to mouse clicks, for example)? Why do we need to invoke new hardware to be responsible? Perhaps some collision between the event structure (which also handles mouse clicks) and Wait on FP Activity is triggering some sort of race condition where each tries to handle the same interrupt, but some resource has been freed, leading to an "attempted to access pageable memory while the process IRQL that was too high"?
The old VT100 hardware has been chuntering along reliably for about 3 years now, I'm very skeptical this is where the issue lies. To satisfy your curiosity, this is the device, (note those last couple of bullet points... fun stuff), it spits out strings that look like this:
where those escape sequences are interpreted by hyperterminal (or me, in labview) via a mapping such as from here to make up something that looks like this.
(aside: did i really need to do this just to copy that text to be able to post it??!)
wrote: wrote: ...
Maybe it's what you do when it's been inactive is what's crashing the computer.
It's in the snippet - I switch a couple of switch-on-release booleans. That's all. Most of the time even the value doesn't change, it's only there as a precaution after all.
What do those booleans do? Perhaps you have created (or exposed) a race condition. In any event I don't recall ever using that Wait on Front Panel Activity function. I've found an event structure to be more than adequate. Also, the Elapsed Time express vi is nice when you need to perform a function after a given time.
wrote: I don't think typecasting is working.
I have used I32 and the result is coming in negative. But probe output is a positive value.
Well that is because a refnum is simply a magic cookie whose actual value has little meaning except to the LabVIEW context in which it was created. And as such LabVIEW tends to prefer unsigned interpretation for such values. So why not typecasting it to an unsigned 32 bit value if you don't want a sign?
Still you haven't answered the reason you want that, the numeric value of a LabVIEW refnum is completely meaningless to anyone but LabVIEW itself and also only in the LabVIEW application context in which it was created. The probe window has to somehow display a value and that is why it shows the numeric value rather than a long string of binary data that the underlaying object may contain to which the refnum refers to. What the actual object data is is totally private to LabVIEW and very different for different refnum classes.
Also there is no way to get at the interna of such refnums as they are not really pointers but magic cookies that refer to the data in a magic, LabVIEW private way.
Thanks for your help. I haven't included the array in my gtype and everything works now.
The type cast vi is complaining as soon as I connect a gtype to its type input. I get the error "Polymorphic terminal cannot accept this data type. Wired type: dummy.gtype"
cast it as a U32, not an I32
The booleans disable background reads. On the main event structure timeout, they control a case structure; if enabled, a background read is performed, if false, one isn't. They're mechanically switched, not latched. Shouldn't be any race conditions.
wrote: The booleans disable background reads. On the main event structure timeout, they control a case structure; if enabled, a background read is performed, if false, one isn't. They're mechanically switched, not latched. Shouldn't be any race conditions.
Where else in your code are you switching the controls? What happens if one is switched and the other is not (a race condition in which one gets updated from your code and then they both get read before the other is updated)? If this piece of code is really the problem then the problem likely exists in how it interacts with the rest of the program.
Sorry for the thread resurrect, but, the one valid case I can think of is if you are inheriting a huge mess to refactor, at least in my case, the top level VI is so large (read: no flow, no structure, no modules) that moving things around and cleaning up is super slow, and moving over structure boundaries is super slow because it starts trying to resize etc.
Gregory's answer already told you that there are likely two types of drivers you may need to install (well possibly even three if you use the GPIB interface).
First the device supports RS-232, Ethernet and GPIB connectors on the back. As far as configuration goes, GPIB tends to be the most simple as you just need to make sure that the GPIB address in the VISA resource name matches the address set in the device (address 2 by default).
As to drivers you typically have an instrument driver which is simply a LabVIEW library that provides VIs that format strings to send to the device and parsing the response to return the data in a meaningful numeric manner to the caller. These instrument drivers usually use NI-VISA which is a middle layer driver software from NI. NI-VISA then calls into system drivers for the according hardware interface, for GOIB this is the NI-488.2 driver software which you need to install for your NI-USB-GPIB interface. For RS-232 it calls the OS specific serial port API and for Ethernet communication it calls the network socket interface provided by the OS.
For a LabVIEW driver using NI-VISA the actual interface used almost doesn't matter as VISA abstracts those differences away. There are usually only two areas where one needs to do interface specific handling in the instrument driver. One is the Initialize function where you open a connection with the device. Here you need to configure things like baudrate for serial ports and message termination character for serial and ethernet. VISA does allow to set some property to let it append the message termination character to each string send out but I prefer to do it explicitly in each command string as the additional message termination character normally doesn't hurt in GPIB operation either for devices which support multiple interfaces.
If you download the Stanford Research SR1 driver from the instrument driver Network you can see in the Initialize method that they do some specific initialization handling for when the VISA session is a serial port connection. A similar case frame would be needed for TCP-IP without the baudrate and other serial port specific properties.
Now your device is a Laser Driver so the actual commands from the SR1 Analizer won't make much sense for the most part. But it gives you an idea about how an instrument driver can be build that will support multiple interfaces with your device. If done properly your driver can work with any of the three interfaces with just using a different VISA Resource Name identifier connected to the Initialize method of the driver!
Hi everyone,
I have one cDAQ 9188 chassis and I am using Labview version 16.0f5(64-bit). The labview program contains DAQ Assistant and once in a while I get error -50405 and as a possible reason, it says "No transfer in the progress because the transfer was aborted by the client". Sometimes it works for half an hour without any error, but sometimes the same error window appears every 2 minutes.
Any help or suggestions would be appreciated.
Thanks in advance.
Deniz
wrote: cast it as a U32, not an I32
Yes of course, my bad. 🙂
/Y
