Jump to content

.NET: Citizen.LayoutUtilities.Printing - Controller.Open() open fails

Recommended Posts

Hi guys,

maybe you can help me there with an .NET issue.
I try to use the Controller.Open() method from the Citizen.LayoutUtilities.Printing, but it always reports -1 as an error.
There is no LabVIEW error on the constructor or invoke node and the c# example works fine.


This is the Citizen SDK with the manual and examples:


There are also c# examples included in the SDK which work without problems with the same path/file.



The call as well as the sample code looks not that complicated, not sure what is causing the problem.




I did notice also another strange behaviour with the DLL selection of the constructor.

Adding contructor, choosing DLL the first time:





If I choose the DLL the first time, then the constructor node seems not to to be refering to the DLL.
It's empty and property and invoke nodes do not show anything.

I have to chose then again "Select Constructor..." and select the according DLL again, then I can access invoke and property nodes by the constructor reference without problems.



The second time it works and the node is reffering to the DLL.


I tried it with LabVIEW 2013 as well as with 2020.
Any idea what could be wrong?


Edited by Michael Uray
Link to comment
  • Michael Uray changed the title to .NET: Citizen.LayoutUtilities.Printing - Controller.Open() open fails

Sure, this is the printer driver, the printer is connected via RS232:

This is the SDK with documentation and examples:

I wanted to re-create the "sdk-layout-windriver\Sample_WinLayoutSDKviaPrinterDriver_en\VCS2010\Sample1" in LabVIEW.

It already fails at the "Open()", even the file exists and the file works with the "Sample1" software which came with the SDK.

There is a strange behaviour with the constructor node, I have to select the according DLL files 2 times that the constructor gets valid.

Edited by Michael Uray
Link to comment

You should check that both the DLL and LV have the same bitness, 32 bits or 64 bits, not mixed.

You might be able to bypass the entire problem, if you can create a raw printer file.

1. Create a raw file - usually label printers use a text based encoding (for example, Zebra printers use ZPL, other vendors have similar formats). This will be your template file.

2. If you are using Windows, create a printer share.

3. Set the fields in the template.

4. copy the file to the share - using the system call, issue a copy <filename> \\localhost\<share name> command.


Link to comment

There is something strange about how this library is managed. For some reason it seems to work if the VI is part of a project, but not as a standalone VI.



As part of a project


I did not reproduce the entire example, so it might fail. At least you can try adding your VI to a project and see if it works (make sure the assembly is listed under Dependencies).

Edited by LogMAN
  • Thanks 2
Link to comment

Thanks guys, i missed that with the assembly location.


If I add the vi to a project, then it shows there up as dependency and the VI works properly.
I noticed that I have to open the project first and then the VI and not the other way around.


It also works fine if i put the DLLs into the LabVIEW.exe directory.

Thanks again for your help.

Edited by Michael Uray
Link to comment

Edit: Nevermind, I misread your post 😄

21 minutes ago, Gribo said:

What is the difference between these two methods? If a .NET library is included in a project, does LV load it before the VI is run?

In order for LabVIEW to know about all dependencies in a project, it has to traverse all its members. Because this operation is slow, it probably keeps references open for as long as possible. I'm not sure why it would unload the assembly in standalone, but that is how it is.

Edited by LogMAN
Link to comment

I had to add the files then manually to the project that they also get packed into the application builder setup / bult directory.
I think the easiest way ist to add all the files to an folder an to add then the folder to auto-populating to the project.


Then all the files will automatically show up in the data folder of the built directory.



Edited by Michael Uray
Link to comment

Make sure that you have the rights to distribute those binaries before you put them in your build specification. There is a license agreement that you accepted when you installed them on your machine.

Note that you don't have to distribute those assemblies yourself. Perhaps there is a runtime installer available which your clients can use. As long as the assemblies are installed on the target machine, LabVIEW will either locate them automatically, or you can specify the location in an application configuration file.

Here are some resources on how assemblies are located:

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.