WinGPIB - Windows GPIB App (multi-purpose)

[blackdog]

Hi ian, 


I have two screenshots for you, maybe they help.




And number two.


Kind regards,
Bram

[blackdog]

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

[IanJ]

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

Can you try logging your 3458A only, and if it still crashes use the following additional command in the PRE-RUN

ARANGE 0

This will turn off auto-ranging on the 3458A. I notice that if my battery driven 10v voltage source goes dead then my app will start queueing some errors (doesn't crash though). ARANGE 0 stops the 3458A changing ranges as the voltage drops to zero. Make sure you manually set up the range on your 3458A before you start. Worth a try!

Also, if the 3458A is ok overnight then try the 34461A on it's own also.

Also, on the main app there is an ABORT ERRORS checkbox, you can try un-checking them both.....just to see.

Also, try running without enabling the Chart Devices.

Also, can you expand Task Manager in Windows AFTER it's crashed and tell me what you get in there.....here's mine after I have CREATE BOTH DEVICES, so I want to see if your IO Devices DLL is still running.


PS. So far I have no crashes even running for a few days.......I will test further though.

Ian.

[IanJ]

Hi all,

V1.32 available in post #1.

- Tootips added to many of the Main app and Playback app buttons and entries. Just hover your mouse over. Note: Still have some to do.
- Have added a SCREENSHOT button to the Playback screen. This takes a screenshot of the Playback app only and saves a .PNG to the app folder. Date and Time in the filename i.e. "2018-12-16_10-50-44_Log.png"
  Note: There is a small bug in the screenshot as it doesn't capture everything for some reason (some details missing off-graph).

Ian.

[Messtechniker]

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.

[blackdog]

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

[IanJ]

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

You can use whatever resistors you want, depends on your purpose for the board.
If it's just for soak test / ageing then you don't need 2ppm.
5ppm works well also, and is a lot cheaper.
Also, you don't need to populate the whole board, a channel at a time may suffice your needs.

I am running a long term test also, running the app in debug mode so any problems will hopefully be revealed.

Ian.

[IanJ]

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.

New user so I have my ideas, I will reply again later today once I get back to the workshop. Tweaks may be required.

Ian.

[pwlps]

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

[IanJ]

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 all,

I ran dual device logging (3458A & 34461A) for 24hrs and never had any problem, so it's indeed a curious issue that blackdog is experiencing.
It was running for 24hrs in the debug mode of Visual Studio and no issues were reported, or any resources dropping etc.

blackdog,
I have taken Pawel's new .DLL an included it in V1.33 (see Post # 1).
I have also added a checkbox per Pawel above that gives an alternative way to send the query to Device 1 & 2. See check box "Send Blocking" to enable this mode after you have Created Dev1/Dev2.
When you hit RUN you should see this mode in operation in the Device List pop-up as each device is queried.

Messtechniker,
If you are not seeing any charts/graphs, i.e. just a black box with NOTHING inside it, and no scales down the sides per the screenshots then I think your .NET Framework is probably old.....thats the only reason I can see for this.
You may need to update it via .NET Framework 4.0 installer from Microsoft:-
https://www.microsoft.com/en-gb/download/details.aspx?id=17851
However, this would affect other software on your PC so please make sure it's really what you are able to do.
PS. Win 7 comes with .NET 3.5.1 by default I believe.
Regarding the Playback screen crashing immediately you load the sample log, I think this is exactly the same problem.

I have left version V1.32 in Post #1 until we can see if V1.33 is working ok.

Ian.

[pwlps]

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

[blackdog]

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

[IanJ]

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

Ok, I have uploaded a new V1.34 in Post #1 which includes a checkbox on the Device List pop-up (IO Devices).
"Dev1/Dev2 Interlock" which will give the above functionality that Pawel describes, but it's optional.

Default when unchecked is as normal, checked will disallow concurrent calls.

I am leaving the previous version available to download.

Ian.

[IanJ]

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

Which version are you running?
Are you still logging two devices HP3458A and 34461A...?
Any other changes like a slower sample rate, different PRE RUN & ON RUN commands etc?

Ian.

[blackdog]

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.

[IanJ]

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.

Download V1.34 and log both devices at the same sample rate etc that made it crash before.

When you hit CREATE BOTH DEVICES the pop-up will appear, and on it a new checkbox.........so please check it "Dev1/Dev2 Interlock" before you hit RUN.

On the main app, just leave both "Send Blocking" unchecked.

PS. This new version has changes to the .testIODevice.exe and also IODevice.dll

Ian.

[blackdog]

Hi Ian,

Is is running, we shall se, off to bed :-)



Kind regards,
Bram

[pwlps]

Hi,
and here a very old version - still running in the background on my office PC 
Look at the sample count - you can't beat me 

[Messtechniker]

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. 

[IanJ]

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.

The USB-TnH SHT10 V2 sensor that I use is available via the manufacturers webpage, or sometimes he advertises on Ebay.
http://www.dogratian.com/products/index.php/menu-sensors/menu-usb-tnh-type-a-sht10

I have purchased several times from the guy without problem.

I could probably implement other serial USB sensors but would need one in my hand and with details of the protocol or example code.

Ian.

[Grandchuck]

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).

[IanJ]

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).

Can you email me your log file?....or attach here. Playback is working ok with V1.34.

Ian.

[IanJ]

Hi all,

V1.35 available in post #1.

- Got new code from Pawel (new .DLL file)
- I have added some error checking to the CSV file loading into the Playback Chart.
  Detects for an invalid/empty file and offers a pop-up as a result.
  Auto-detects the delimiter (comma or semi-colon) and sets it accordingly and loads the file. If none found then there's a problem and offers a pop-up as a result.

Ian.

[IanJ]

Hi all,

V1.36 available in post #1.

- Added checks to make sure the necessary data being written to the CSV is ready available to do so.
  I found that if the CSV is enabled before the logging has started, before the temp/humidity sensor is delivering data etc then the CSV can contain bad data which crashes the Playback Chart.
  Now the controls & checkboxes can be made in any order and the CSV file is always correctly written to.
- I have also added more checks to CSV when loading it into the Playback Chart. Pop-ups will advise of any bad data/lines in the CSV on loading.

Thanks to Chuck for sending me his test CSV file which prompted these fixes.

Ian.

[IanJ]

Hi all,

V1.37 available in post #1.

- With all the CSV checks I added......the blank Log.csv I enclose in the ZIP isn't compatible with teh Playback Chart.......it has an extra blank line!....aarrgghh!
   So enclosed with V1.37 is a new blank Log.csv that will work.

I knew that when I started to add checks and balances all over the place that things would break as a result......:-)

Thanks again Chuck!

Ian.