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

[Michael Uray]

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:
https://www.citizen-systems.co.jp/en/printer/download/sdk-layout/sdk-layout-windriver_V1400E.zip

 

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 November 27, 2020 by Michael Uray

[Gribo]

What are you trying to do, print something?

Can you post a link to this driver?

[Michael Uray]

Sure, this is the printer driver, the printer is connected via RS232:
https://www.citizen-systems.co.jp/en/printer/download/driver-windows-en/pmu2xxxiiip_v3501E.zip

This is the SDK with documentation and examples:
https://www.citizen-systems.co.jp/en/printer/download/sdk-layout/sdk-layout-windriver_V1400E.zip

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 November 27, 2020 by Michael Uray

[Gribo]

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.

 

[Michael Uray]

It shows me it is valid for both platforms.

There is a utility with it to create these .CLF template files which I want to use and where the user can change the layout later, content data should get populated into it by LabVIEW.
I run into an error just loading this template file without adding any data to it.

[LogMAN]

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.

Standalone

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 November 27, 2020 by LogMAN

[Gribo]

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?

[Michael Uray]

Thanks guys, i missed that with the assembly location.
https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/net_defaults/

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 November 27, 2020 by Michael Uray

[LogMAN]

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 November 27, 2020 by LogMAN

[LogMAN]

Here is an interesting note: How LabVIEW Locates .NET Assemblies - National Instruments (ni.com)

Quote

National Instruments strongly recommends that you always put VIs that use .NET assemblies in a LabVIEW project and not leave them as stand-alone VIs.

 

[Michael Uray]

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 November 28, 2020 by Michael Uray

[LogMAN]

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:

• Loading .NET Assemblies - LabVIEW 2018 Help - National Instruments (ni.com)
• How the Runtime Locates Assemblies | Microsoft Docs