AppDomain error with Allied Vision Vimba SDK package

[Jordan Guerguiev]

Hi Gonçalo,

I'm writing a custom package to get an Allied Vision Mako camera working with Bonsai using the VimbaNET SDK, based on the PointGrey package you wrote. I think I've gotten close -- the VimbaNET API is being loaded correctly, but when the code tries to get access to the camera using the API call:

camera.Open( VmbAccessModeType.VmbAccessModeFull );

Bonsai crashes with the following error:

System.ArgumentException was unhandled

Message: An unhandled exception of type 'System.ArgumentException' occurred in mscorlib.dll Additional information: Cannot pass a GCHandle across AppDomains.

Since I am very new to .NET programming I'm stumped as to what this error might mean. The example applications provided with the VimbaNET SDK are able to access the camera just fine using the same calls to the API, so I assume something about the fact that the code is being run by Bonsai is leading to this error. Since you're quite experienced with .NET programming I'm hoping you might have a hunch about why I might be getting this error. I've attached my project to this post. Any help is much appreciated!

Best,

Jordan Guerguiev

[Gonçalo Lopes]

Hi Jordan,

Thanks for the contribution, it would be really nice if we can get this to work. I will try to see if I can get access to an AVT camera to try out this code and debug the situation.

I have indeed seen this error in the past, but only once, it is quite obscure. My suspicion is that they are using some kind of COM interop behind the scenes, which may be sensitive to the way the Bonsai process is configured.

In particular, I found this weird post which raises an intriguing possibility:

"Consequently, when calling managed code from unmanaged code, the compiler has to pick one AppDomain to use, and it appears to pick the first one."

Can you try one thing for me? If you start Bonsai from the command line, can you try passing in the flag "--noboot"? Something like:

Bonsai.exe --noboot

This should start Bonsai in single AppDomain mode, and I'm curious whether this will make Vimba work...

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/bonsai-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/bonsai-users/75e02d96-018d-461c-a80b-5dc07a1a6e13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jordan Guerguiev]

That worked! I've got the camera working now. The only snag is that Bonsai needs to be run with the --noboot flag, which might cause some issues? I've noticed the package manager window doesn't work in this mode.

Thanks for the help!

Jordan

On Monday, March 6, 2017 at 5:31:01 AM UTC-5, goncaloclopes wrote:

Hi Jordan,

Thanks for the contribution, it would be really nice if we can get this to work. I will try to see if I can get access to an AVT camera to try out this code and debug the situation.

I have indeed seen this error in the past, but only once, it is quite obscure. My suspicion is that they are using some kind of COM interop behind the scenes, which may be sensitive to the way the Bonsai process is configured.

In particular, I found this weird post which raises an intriguing possibility:

"Consequently, when calling managed code from unmanaged code, the compiler has to pick one AppDomain to use, and it appears to pick the first one."

Can you try one thing for me? If you start Bonsai from the command line, can you try passing in the flag "--noboot"? Something like:

Bonsai.exe --noboot

This should start Bonsai in single AppDomain mode, and I'm curious whether this will make Vimba work...

On 6 March 2017 at 01:15, Jordan Guerguiev <guerg...@gmail.com> wrote:

Hi Gonçalo,

I'm writing a custom package to get an Allied Vision Mako camera working with Bonsai using the VimbaNET SDK, based on the PointGrey package you wrote. I think I've gotten close -- the VimbaNET API is being loaded correctly, but when the code tries to get access to the camera using the API call:

camera.Open( VmbAccessModeType.VmbAccessModeFull );

Bonsai crashes with the following error:

System.ArgumentException was unhandled

Message: An unhandled exception of type 'System.ArgumentException' occurred in mscorlib.dll Additional information: Cannot pass a GCHandle across AppDomains.

Since I am very new to .NET programming I'm stumped as to what this error might mean. The example applications provided with the VimbaNET SDK are able to access the camera just fine using the same calls to the API, so I assume something about the fact that the code is being run by Bonsai is leading to this error. Since you're quite experienced with .NET programming I'm hoping you might have a hunch about why I might be getting this error. I've attached my project to this post. Any help is much appreciated!

Best,

Jordan Guerguiev

--
You received this message because you are subscribed to the Google Groups "Bonsai Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users...@googlegroups.com.

[Jordan Guerguiev]

Almost forgot, I've attached my working code.

[Jordan Guerguiev]

Also, I forgot to mention, but I had to add a file called Bonsai.exe.config to the Bonsai directory with the contents:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <startup useLegacyV2RuntimeActivationPolicy="true">

    <supportedRuntime version="v4.0" />

    <supportedRuntime version="v2.0.50727"/>

  </startup>

</configuration>

In order for the Vimba DLL to load. I'm not sure if it's possible to make this part of the package rather than having to put it in the app directory, but I wasn't able to figure it out.

[Gonçalo Lopes]

Hi Jordan,

I'm very happy to hear that you got the Vimba SDK working with Bonsai. Before we go into the difficulties you have encountered, I want to ask: would you be opposed to making the source code for this project available online in a repository? This way, when we eventually evolve the project into a package, we can point users to the bitbucket or github website.

If you like, I am more than happy to assist you on this, and also in adapting the code to make it into a NuGet package that can be shared in the community repository with all other users.

Regarding the two main difficulties, both the AppDomain and the config file, these reveal some clear design decisions by the developers of AVT's Vimba.NET wrapper. Specifically, it is clear that they are using C++/CLI to implement their wrapper around the original C++ SDK and also that they are using a version targeting the old .NET framework 2.0. This is most likely for fear of losing backwards compatibility.

Unfortunately, there is not much we can do at the moment to completely resolve these limitations. For now, managing different AppDomains is what allows Bonsai to be able to install and uninstall packages on the fly (which is why you found that the PackageManager does not work under the "--noboot" flag). Also, it is not possible to setup the legacy .NET 2.0 runtime activation from other configuration files.

However, I did find a blog post suggesting that it is possible to activate the legacy .NET 2.0 runtime programatically: http://reedcopsey.com/2011/09/15/setting-uselegacyv2runtimeactivationpolicy-at-runtime/

In this case, it might be possible to fix the issue within the plugin code itself. If you want, you could give this a try, although we should consider whether we want this to be an appropriate long-term solution. The blog post author himself advises against it and I can understand why global runtime behavior changes triggered by local plugins could lead to unexpected behavior that is hard to track and manage.

Ideally, the Vimba SDK will move on from the .NET 2.0 soon enough...

Even with the remaining AppDomain limitation of having to launch Bonsai separately with the "--noboot" flag, I still think it is worth it to have the plugin widely available. Accessing AVT cameras with the Vimba SDK would help out many users and really the only thing that is disabled by launching Bonsai with this flag is the package manager. Everything else should work appropriately. For the long-term, I am considering to stop using AppDomains anyway in order to compile Bonsai with .NET Core (cross-platform .NET) support for Bonsai 3.0 and beyond. Perhaps by that time this will all be solved anyway.

Anyway, let me know how you feel about the plugin source code repository and whether I can be of any help setting it up.

To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/bonsai-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/bonsai-users/ccac4863-2a5f-41c8-ab34-77116d716cb8%40googlegroups.com.

[Jordan Guerguiev]

Hi Gonçalo,

My apologies for the late reply! That trick for activating the .NET 2.0 runtime programatically seems to work, so I've made that a part of the code for now. The only thing necessary for running the package now should be launching Bonsai with the --noboot flag. I've made a repository with the current project on GitHub:

https://github.com/jordan-g/Bonsai.AlliedVision

and I've posted a NuGet package to the gallery:

https://www.nuget.org/packages/Bonsai.AlliedVision/

Let me know if there are any problems with the way I've made this available, and future steps that should be taken.

Thanks,

Jordan

[Gonçalo Lopes]

Hi Jordan,

Cool, thanks a lot for making this package available! I think hosting the repository on github is great.

I went through the code and package specification and overall I think everything is really great! Thanks for following all the Bonsai code and packaging styles, it really helps consistency and readability :-)

I have just a couple of feedback points to improve this (and future) packages:

1. Regarding package distribution, if you want it to be visible to all Bonsai users by default, you should actually upload the package to the community MyGet repository instead of NuGet. Here's the repository link:

https://www.myget.org/feed/Packages/bonsai-community

You should be able to create an account on MyGet and simply push your existing package there. This way, all users will see it even if they don't have "nuget.org" configured as a package source.

2. I see that you released already two versions of the package. This is fine, but I also noticed that you incremented the version from "1.0.0" to "1.0.0.1". The first version was correctly formatted using the guidelines for Semantic Versioning, which all Bonsai packages follow (and NuGet recommends), but the new version broke out of this format, which uses only three version numbers. I would recommend that whenever possible, packages follow the SemVer guidelines for every release.

Furthermore, I would also recommend that whenever the release is just a patch or bug-fix, the actual managed assembly version attribute does not need to change. The reason is that if the release is simply a bug-fix, it should retain full API compatibility with other versions of the same library, which means that it should be possible to upgrade the dependency even if other workflows and libraries that depend on it are not themselves upgraded.

To summarize, I would have upgraded the AssemblyInfo.cs file like so:

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
[assembly: AssemblyInformationalVersion("1.0.1")]

3. For future projects, I have started to begin the version number at "0.1.0" rather than at "1.0.0". Again, this is following SemVer guidelines. The reason is that in the first few versions of a project it is expected that the API may not be very stable, and can change a lot. The "0.x.x" versions represent this state, and help mitigate the need to release too many "major" versions in the early stages of an API.

Nevertheless, this is not critical at all, and it's really just a recommendation for the future, there is no need to change this now.

4. I noticed that the project depends on the Vimba.NET managed libraries, but the package itself does not contain the DLL files. This means that users will not be able to run the package immediately after download, since there will be missing dependencies. Is this intended? What actual dependencies are required in order for the Vimba SDK to run? The best way to figure this out may be to try installing the package on clean machines and see what is needed.

Also, there are probably both 32- and 64-bit versions of these dependencies that should be indicated in the package so that Bonsai knows which version to load. Let me know if you have questions on this bit and I can help organize.

Thanks again for all your efforts!

To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/bonsai-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/bonsai-users/a8eb9baf-6dc1-4238-96d8-adbde89d1835%40googlegroups.com.

[Jordan Guerguiev]

Hi Goncalo,

Thanks very much for the help! Following your PointGrey package I've updated the project to include the Vimba.NET dlls (previously it referenced the dlls that would be placed in the Program Files directory created by the SDK installer) and I've submitted an updated package to the MyGet community. I'm planning to add some features like the ability to set properties such as frame rate, exposure, etc. from Bonsai in the future.

Best regards,

Jordan

[Ivo Sonntag]

Hi Gonçalo and Jordan,

I wasn't sure if it makes sense to start a new thread on this, so I didn't.

I also posted the same question as issue into Jordans Bonsai.AlliedVision Github repo to make sure it's easily found.

We have the following problem:

We'd like to use your Allied Vision Bonsai package, but encountered some issue that causes Bonsai to crash. There'r 2 screenshots attached, the first showing the error message displayed within the Bonsai Gui, and the second showing the cmd error.

We tried both 32/64 bit Bonsai versions and used two different computers (win7/win10).

Also the --noboot flag for starting Bonsai was used. The Vimba SDK is installed and its possible to use the camera through the SDK.

Bonsai appears to be able to open a camera connection, but then produces an AccessViolationException. we contacted Allied Vision about updating the firmware since the camera is an older model.

Did you encounter a similar error when you developed the package?

I'm hoping a firmware update is simply going to fix it. We're also considering simply getting another camera.... 

Still If you have any idea on what might be going on we'd be happy to follow up on that.

Best,

Ivo 

[Gonçalo Lopes]

Hi Ivo,

I'm sure Jordan would be a better person to comment on this, but I would say your idea of updating the firmware is definitely a good thing to try. We've had similar issues with drivers from different cameras. Maybe you could also share which version of the Vimba SDK you have installed in your machine?

It could be a mismatch between the version you are using now and the one Jordan used to compile his AlliedVision package.

To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/bonsai-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/bonsai-users/0965f33b-81f3-4f07-858a-dba3636f6d23%40googlegroups.com.

[Ivo Sonntag]

Hi Gonçalo,

we updated the firmware but are still getting the same error.

The Vimba API Version is 1.7.0. 

To update the Firmware we had to install the AVT FirePackage because the Vimba SDK does not support updating the firmware on older models.

Do you still have the code for the older Bonsai package running AV cameras?

Best,

Ivo 

[Gonçalo Lopes]

Hi Ivo,

Judging from Jordan's github repo (line 110), it seems that he used Vimba 1.5 to compile the package. It could be that this would be solved simply by recompiling his package with the new Vimba 1.7.

Alternatively, if you can get a hand on it, you may try to install the old Vimba 1.5 SDK and see if that works.

Regarding the old FirePackage, you can find it here:
https://groups.google.com/forum/#!topic/bonsai-users/Owp15XWvmuc

It's been some years since I've tried it though, so not sure how well it will hold out with the drivers you installed.

Hope this helps.

To unsubscribe from this group and stop receiving emails from it, send an email to bonsai-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/bonsai-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/bonsai-users/cbaca239-ce73-4b25-b372-3eaa87fd96a4%40googlegroups.com.

[Alicia Alonso]

Hi! I experienced the crashing problem whenever I was trying to start the VimbaCapture node in Bonsai and after using the Bonsai.exe --noboot flag I could solve it. However, I can't manage to visualize the video while the VimbaCapture is on. What should I do in order to visualize the video and save it?

Thanks in advance,

Alicia

To view this discussion on the web visit https://groups.google.com/d/msgid/bonsai-users/cbaca239-ce73-4b25-b372-3eaa87fd96a4%40googlegroups.com.

[Gonçalo Lopes]

Hi Alicia,

Can you clarify what you mean by "visualizing the video"? You mean by double-clicking on the VimbaCapture node? You need to right-click on the node and select the Image first, as the node is sending out a data packet that contains both metadata and the video frame.

If in doubt, please attach the workflow you are trying to use and / or a screenshot of the issue.

Hope this helps.

To view this discussion on the web visit https://groups.google.com/d/msgid/bonsai-users/08085bcb-a41b-42b7-a171-c95886e855f9n%40googlegroups.com.

[Gonçalo Lopes]

Hi Alicia,

I am replying back to the forum. I believe you need to configure the ExposureTime together with the FrameRate, otherwise if the time of exposure is too high the driver will not be able to deliver the target frame rate.

Hope this helps

On Mon, 14 Dec 2020 at 09:22, Alicia Alonso Andres <a.al...@umh.es> wrote:

Hi Gonçalo, the other day I could make it work by doing exactly what you just said. However we have a new "problem" now: whenever I try to chose the frame rate (since we have a high speed camera we would like to use its maximum which is 500 fps), and I run the workflow, there is an error message and it stops working. The fps in the VimbaCapture node are set to 49 by default, how can I correctly set it to record at 500 fps?

Thanks in advance for your time.

Kind regards,

Alicia