Ni-Scope Single Sweep

[RTSLVU]

---

@mcduff wrote:

Go to the View in the menu and and open "Event Inspector Window"

I have not looked in detail at your code, but you have multiple event structures and value signaling properties. I wonder if your Event is getting triggered twice, then two acquisitions.

The Event Inspector Window has a log of events, check if that is the case.

mcduff

---

That's what I was thinking... I am kind of been in a quandary ever since some manager had the brilliant idea of moving us to a VLM.

I can not install LV on the target computer. Best I can do is use the remote debugger and even that is a PITA because the test system and my development system are on two physically different networks. 

So my troubleshooting is purely theoretical, bug fixes have to be compiled, deployed, and tested. 

[mcduff]

---

@RTSLVU wrote:

---

@mcduff wrote:

Go to the View in the menu and and open "Event Inspector Window"

I have not looked in detail at your code, but you have multiple event structures and value signaling properties. I wonder if your Event is getting triggered twice, then two acquisitions.

The Event Inspector Window has a log of events, check if that is the case.

mcduff

---

That's what I was thinking... I am kind of been in a quandary ever since some manager had the brilliant idea of moving us to a VLM.

I can not install LV on the target computer. Best I can do is use the remote debugger and even that is a PITA because the test system and my development system are on two physically different networks. 

So my troubleshooting is purely theoretical, bug fixes have to be compiled, deployed, and tested. 

---

Go to VIPM, install NI Event Logger Library. There is an example VI that shows how to log events programmatically, you can try that.

mcduff

[JÞB]

If you are on a vlm.  Get a debug deployment license!  Load and test source code in situ the deploy the working exe.

[BertMcMahan]

---

@mcduff wrote:

---

Go to VIPM, install NI Event Logger Library. There is an example VI that shows how to log events programmatically, you can try that.

---

Thanks for that! I looked briefly, but does it have a built-in way to limit messages to, say, one month, or 1000 entries, or something like that? I've got a customer who might benefit from this, but he runs his software 24 hours a day for months on end. It would be nice to log stuff but not if the log gets to be enormous over time. You could do it manually of course but if there was a built-in way to do it that'd be nice 😉

[mcduff]

Actually, after recommending it, I looked at it more closely. It is not using the Event Logger API. Below is a link using the event logger API (this is what I meant to recommend), you can bundle it in your program and decide how many events you want, rotate files, etc.

The link below is what I recommend using after modifying to meet your needs, not the VIPM package I said earlier.

https://forums.ni.com/t5/You-May-Not-Know/Programmatically-Inspect-Event-Queues/ba-p/3549367

I modified the linked example to send the Events to a queue that I could save to file. (Beside events it records State Transitions, see below how events are recorded, see the Panel Close Event and User Events.)

Time           VI                                   Command/Event
1.616284	   Main.vi             	         Panel Close?  Main.vi
1.616284	   Main.vi             	         User Event  Macro: Exit
1.616284	   UILoop.vi           	         User Event  Macro: Exit
1.616337	   InstrumentLoop.vi   	 Macro: Exit
1.616362	   InstrumentLoop.vi   	 UI: Front Panel State >> Close
1.616365	   UILoop.vi           	         Macro: Exit

mcduff

[Bob_Schor]

I recall a method I think I cribbed from an NI Error Log VI which assumes that entries are "relatively infrequent" (say < 1/sec).  Here's the algorithm:

1. Open the Log File.
2. Get File Size.  If bigger than a "Maximum Size",
   1. Compute "Half Max Size".
   2. Go there, read rest of file.
   3. Rewrite the File, putting second half at the beginning and discarding the first half.  Be sure to reset the (new) File Size.
3. Write Log Entry (at end of file).
4. Close File.

This opens the file, writes at the end, then closes the file, so a crash doesn't destroy the file, and the length doesn't grow beyond a size that you determine (well, not entirely true -- it assumes the entry itself is a "reasonable" size, and doesn't check if adding the entry puts you "over the limit" ...).

Bob Schor