Morning Ian,
This morning at 5:47 the program stopt working.
In the event data i found this string: System.OutOfMemoryException bij System.Array.Resize[[System.Byte, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]](Byte[] ByRef, Int32.
This is a picture of the error log from ".net"
And this picture of the error "testIODevice.exe"
This is a screenshot of the directory your software is in, the file at the bottom "Zaterdag-01.csv" also stopped at 5:47 which is logical.
Here is nothing special visible, there is also plenty of memory left, more than 6GB free.
This is the beginning of the logfile.
And the end of the logfile.
This time around 15 o'clock the software has been logging and the file size is just over 1MB.
I have no idea if these two things have anything to do with the error, except the one: System.OutOfMemoryException remark in the log files.
The computer works normally after your software has crashed.
I hope this helps.
Kind regards,
Bram
Hi Ian,
Your software now runs for about 25 hours with only the 3458a.
It is not yet crashing and the logfile is afther 25 hour around 850KB.
If it does go wrong, I will go to your proposed taskmanager settings, and yes I am lagging behind with the software version, that's because your software is still working.
This morning a parcel was delivered, and what do you think it contained, TADA.... An Inan LM399 test print!
It is a nicely made print, now save for the parts, the 2ppm resistors are on the expensive side in small amounts.
Kind regards,
Bram
Just joined the club with my 34465A.
Works so far on W7 32 Bit. Logging and .CSV are OK, but no curves.
Playback crashes even upon loading LOG_sample.csv.
Will look into this tomorrow possibly on another PC.
Hi Ian and blackdog,
As the error is triggered from my library it seems it's my job to answer this one.
This is weird: the "AccessViolationException" should never be thrown by a managed code but here it looks like it came from an internal NET routine (the WaitHandle.WaitOne method). Does it mean a bug in NET or it was just by accident that the error appearing elsewhere has been trapped just there? I found other threads reporting such errors on stackoverflow and msdn forums but with no clear indications on the possible reasons.
Several options to explore:
1) I see that the NET version is 4.03..something, and I know that there were a lot of changes in the way threading is handled between the version 3.5 and 4 so maybe there is a problem in this early version.
I have been using the library under v3.5 in a heavy-duty environment (acquisition with many instruments scanned in parallel, running 24h/24h for months, also under Win7 64bit), but did not make such tests under 4.0. Maybe it would be a good test to try the app under 3.5 : Ian, could you make a "downgraded" version of the exe compiled with v3.5 ? ("Target Framework" in compiler options).
2) Ian, you could also add a checkbox to select between async and blocking querying mode. Of course in blocking mode the acquisition with more than one device will be slower (especially at higher NPLC) but this could provide a sort of fall-back option where any bugs are much easier to trace because everything is done on the main thread.
3) I will send Ian a slightly patched version of the main file, with the error being catched (only for NET 4.0 and higher) - but I'm not sure it can help.
I have no idea about the "out of memory" error (this might possibly also be triggered by an "access violation" error somewhere else), the only way to get more information would be to run the program under the debugger.
keep me updated
Pawel
Hi Ian,
Here is another suggestion.
From last Bram's posts I see that the error occurs when he connects two devices, one via gpib and another via hislip, but it seems to disappear when there is only one device. This points to a possible problem with simultaneous calls to Visa. My library tries to optimize the speed following the official Visa specs saying that it is thread-safe, i.e. the default configuration allows concurrent Visa calls. However this behavior is entirely configurable as I explan in the article, section about lock levels. The concurrency is governed by the field "interfacelockid" set by the class constructor and you can easily change it in the code. In the file VisaDevice.vb you will find (method "create" called by the constructor) the following piece of code which sets this field :
If addr.ToUpper().Contains("GPIB") Then
Dim gpibboard As Integer
Dim gpibaddr As Byte
IODevice.ParseGpibAddr(addr, gpibboard, gpibaddr)
interfacelockid = gpibboard + 10
Else
interfacelockid = -1 'no interface lock for non-gpib interfaces
End If
The reasons to do it this way are explained in the article.
But you can replace this piece of code by e.g.
interfacelockid = 25
With this setting all Visa devices will share the same lock whatever the physical interface so that it won't be possible anymore to transfer data via hislip and gpib at the same time: the thread will always wait until the other transfer is complete, hence some loss in efficiency is expected. However if you only transfer short strings this might not be a problem.
If you try it I will be interested to know if it helps. Visa is said to be thread-safe but I haven't seen many apps using it extensively in multithreaded environments, on the other hand I saw several reports about Labview crashes when using concurrent Visa calls.
Pawel
Hi!
Program is running now for 32H and the logfile at the moment is 1.079MB.
We wil see tomorrow how it going.
I get a better filing about it now
Thanks again for al your work Ian and Pawel, your work is really appreciated by me.
Kind regards,
Bram
Hi Ian,
Iam still logging with version V1.29, i cant keep up with al your versions
Do you want me to stop logging with this version?
It is only doing my 3458A.
Look still running
You can tell me what you want and i will start it before i go to bed.
Kind regards,
Bram
PS
Range set on 10V and 100PLC.
When graphing throws errors it might help to change in Windows
the language from in my case DE to EN. Now properly displaying
5100 samples at a sample rate of 5. Nice
Next I'd like to log temp and humi. Are the recommended sensors available in the EU?
Would save me customs trouble and cost.
Just received the sensor Ian has mentioned and it started working immediately with no hassles.
Strangely, though, am now not able to playback my .csv log file. The one included in the zip package is fine. Has nothing to do with the sensor. The error message is "conversion from string """" to type 'Double is not valid.
Looking at Ian's file and my own does not reveal any differences? I know Playback used to work (some versions back).