Neil Pate

Thanks Phillip,

I did actually try there first, there are some nice threads on zebra specific stuff, but the forum would not allow me to post for some reason!

Will try again.

Firstly, although I was able to get the custom VISA driver to work (USB Zebra printer) I have reverted back to this technique for getting the printer to work. Have had good success with it.

Now onto my problem. I want to print a logo on a label and am struggling to get the ^GF command to work properly (with binary data). I can successfully print a stripe pattern but am not having any success printing the actual logo. In the attached code (very rough prototype code just to get me up and running) I can print a stripy pattern (0xF0, so 11110000 alternating gives me columns of printing in the desired dimension) if I change the selector input to a T (to print my bit-packed logo) nothing prints and the printer seems to get stuck. I do not understand what the problem is as I just assumed, even if my logic for packing the logo into bits is incorrect, I should still get something printed. If I force the top bit high in my bit packing routing I get something printed but obviously not what I expect.

Any ideas what could be wrong? I have tried lots of variants of this code without any success. I am stumped why it does not print. My only conclusion is that Windows is mangling the string commands because technically I am sending null characters and backspace etc in my binary data, but I really just assumed the printer would interpret this stuff correctly.

logo (64x64).bmp

Print Test 5.vi

Rolf, I did see the Rect input, but at the time I did not really consider it useful as I did not know that the problem was related to the image size. Now that you have pointed this out I think that would definitely have helped. I am still getting strange out of memory errors which I have no been able to track down but I strongly suspect are also due to the Picture control functions. Time to use the Rect input I think!

I do not do too much vector darwing, but under some (error) circumstances I have realised the coordinates of my drawing instructions could actually get quite big (as in 32k *32k), I just assumed the picture would be constrained in size to the size of my pixmap data which is not huge, but probably given what you say this is actually causing the out of memory error.

Knocked up a test VI to simulate this error condition and I think this is exactly what is happening for me. A line being drawn from (0,0) to (32000, 32000) and then an attempt to get the pixmap will definitely cause problems!

Nice link. I had seen some of Norm's earlier stuff on the internal implementation.

For now I have worked around my problem by not using that VI, when I get a moment I will investigate my problem further as I would like to understand why it is happening.

It is interesting to peek inside the picture control VIs and realise they really just implemented as strings. Also it is useful to know most operations are additive (i.e. makes the string longer, even if you perform the same action like draw the same line twice). The offending VI that was causing me problems is password protected, but it just wraps the DLL call PictToPix so this did not really help me. 

Tim, I am updating the picture control once per second with (potentially) an entirely new picture of 540x960 pixels, although I could easily cause the condition using the same image that has already been successfully displayed.

Hi gang,

I have just gotten to the bottom of a rather nasty bug that can cause an out of memory error in LabVIEW.

It seems that under certain conditions that I cannot easily recreate in simple code the Picture To Pixmap primitive will attempt to allocate infinite memory. This manifests as a virtually instantaneous increase in the LabVIEW (or built exe) process up to the 2 GB limit and then the "out of memory" dialogue.

The only input to this function I am using is the picture which I have formed using the standard primitives (so no trickery going on with me attempting to create the picture using string manipulation that I know is possible but have not attempted).

Anybody else seen this?

Thanks Thoric, I did quite a bit of googling but that forum link did not come up.

Guess I will have to live with a non-LabVIEW solution (for now).

Actually this WinExplorer application is not part of the SysInternals Suite (which yes does rock without doubt). I was just poking around now in the SysInternals Suite to see if they have something similar but cannot find one.

Strangely it seems there are two "somethings" for my LabVIEW executable (a LVDChild and a LVFrame class). Unfortunately this WinExplorer software does not seem to have support for the  WS_EX_NOACTIVATE  style.

I suspect LabVIEW is doing a lot of its own window management behind the scenes. Bah humbug.

Yeah, I suspected the same thing so I tried building an exe. It behaved the same as in the IDE.

I am going to try this. 

Hi All,

I am trying to make an on-screen keyboard (OSK). I have previously created a nice one that works perfectly if you can feed in the reference of the control that has focus. However I cannot seem to reliably get a unique control reference for several circumstances (e.g. an element of cluster that is inside an array). So I decided to try and make my own, in the spirit of the code of this open source project: https://sourceforge.net/projects/numpad-emulator/files/latest/download?source=typ_redirect

The crux of my current problem is that whenever I click on one of my buttons of the OSK the focus is brought to the new window, and therefore I cannot direct the text into the control that previously had focus. I believe the way to solve this is to use the WinAPI to set the Extended Window Style of my OSK to be WS_EX_NOACTIVATE. According to MSDN "this style allows a top-level window created with this style to not become the foreground window when the user clicks it. The system does not bring this window to the foreground when the user minimizes or closes the foreground window". This is the technique used by the Numpad application I have linked to earlier and works perfectly.

Attached is my attempt. The hex style 0x8000108 is what Numpad uses for the window style. I can successfully control this application from my LabVIEW test to turn on or off the NOACTIVATE by setting or resetting the greater "8" bit in the config. This just does not work for my LabVIEW window though.

Any ideas?

Num Keypad.vi

On 2017-6-16 at 6:34 PM, LogMAN said:

I don't remember them resetting when duplicating events. At least this is working fine in LV2015, so maybe it is specific to LV2013?

Only when adding new events the nodes get reset, which is indeed quite annoying.

Hmmm, I cannot seem to recreate that behaviour either, but am pretty sure I have seen something similar.

I have always actually disliked the fact that if you duplicate an event the IDE resets the Event Data Node to the full set. I have probably had this bug in the past but never actually noticed it.

Thanks for confirming Antoine. I have filed a bug report (for LV2017).

The first rule of the beta is...  ;-)

Hi All,

I have recently discovered a subtle, but potentially disastrous, bug that can cause the Event Data Node to get confused as to the order of items which appear. I noticed this bug in LV2013 SP1 and have verified it still exists in LV2015 SP1.

Please can somebody try recreate this on their system. I have not bothered installing 2016 and 2017 yet so cannot verify if the bug still exists.

To recreate the bug:

1. Open the attached VI. Notice the NewVal output is used. Also notice the Source element has been hidden.
2. Add a new event, the Slide Value Change event to the existing Numeric value Change event. Notice the Source element is now present again and now OldVal is used

ES Test.vi

Why don't you just use a classic display and colour the background transparent?

13 hours ago, jacobson said:

 Connecting to NI OPC Server from a third party UA client is not going to work and a Wireshark will show the server return Service Fault BadOutofMemory.

Just so I am clear here you are making the distinction between OPC-UA and plain-old OPC?

As long as I can connect to OPC-UA server from an OPC-UA client this is good enough for me. 

Don't forget .NET calls in LabVIEW are extremely slow compared to DLL calls, something to do with the managed memory aspect. I seem to remember even simple calls taking several ms to return. 

Got this solved "hopefully". I gave up on trying to mimic this in MySQL as my actual system will use MS-SQL anyway. I rolled out a MS SQL instance in AWS and everything pretty much just worked. Specifying the datatype for a column as datetime2 allows me to insert and query with precision of 7 decimal places :-)

Thanks James, I have probably just labelled my code poorly, when I set the "Re-entrant" flag to true it is because I want multiple clones.

Just stumbled on the toolkit from SAPHIR (thanks smithd for the heads-up in the other forum post). Pure TCP/IP implementation.

http://forums.ni.com/t5/Example-Program-Drafts/Native-LabVIEW-TCP-IP-Connector-for-mySQL-Database/ta-p/3496603

http://www.saphir.fr/en/produits/gdatabase-for-mysql-7.html

Worked first time 

Now I just need to figure out if it is worth $700 , and I have just realised that this is MySQL specific and I need to actually interface with MS-SQL for my real system.

As an aside I am pretty shocked at how simple a basic TCP/IP connector is.