LogMAN

The controls have different names from one picture to the other. They are the same controls, right?

Yeah sorry for that one, I use a translation tool to automatically translate translatable objects on the Runtime system.

The source is in English and the target in German. However the controls are the same and the translation has no effect on the positioning. <-- Tested that one already

How do you know the fonts are the same? Have you explicitly changed the font in the development environment? If the control is set to, for example, Application Font then this will probably be different across XP and 7.

The font is indeed Application Font. Therefore the target system might display stuff a bit different (as with the tab control text width). I'll try that next time I get access to the system.

This is almost always caused by font changes between systems (e.g. if you use the system font or application font, which would be different between XP and 7). It probably only affects some of the controls because the different controls have different fonts.

 

Try setting the controls to a specific font to see if this stops happening. Alternatively, make sure that LabVIEW.ini and your app's INI file have the same AppFont and SysFont (or whatever they're called) lines.

All controls have the same font. I don't understand how the font type or size should effect the position of the control, but I checked it anyways.

On my last post I attached some pictures with an alternative background for the tab-control (the bluish thing...)

I accept that the font does have an impact on the position of the text itself (the background seems to small, but actually the text changed its width).

What beats me is that if I make a shift-right / shift-left in the dev-environment the Runtime does sometimes look just fine... Is there some kind of raster that I can't see?

Can you post screenshots of what it looks like on your dev box versus the XP target.

I had no access to the machine untill right now. Find the pictures attached.

Notice that some items move positions and the blue background-item (or how to name it) is shortened.

LabVIEW Environment (Win7 + LV2011)

Runtime Environment (XP + LV2011RT)

Hello everybody,

I've got a situation where some controls change their position on the build application however only on the target system.
This is not just limited to a specific type of control and it does not even effect all controls on the same FP.

Up till now the behavior seems to be limited to controls inside a tab-control.

Does anybody had experienced a similar behavior with such a setup?

This issue might be related to that topic: http://lavag.org/topic/16911-prevent-control-resize-when-changing-monitors/

However my controls change their actual position, where the related topic changes height & alignment (of the text inside).

Just figgured that I misunderstood the issue...

I'll open a new post!

It's back online!

Jim, where is "Get Enum String Values" VI? I googled it and tried to find it on LAVAG without success.

Refer to http://sine.ni.com/nips/cds/view/p/lang/de/nid/209027 for information about the OpenG toolkit. It includes the VI you are searching for (see jcarmodys post for a picture).

An alternative option to this solution is to use the property node of the Enum directly. Configure it to return the Strings[].

The problem is down to line 3425 out of 3743 (only about 20 more feeds to go!)

I guess the RSS will be back online for all in approx. 2 Weeks

That is weird, I try to load it in Internet Explorer, Firefox, Thunderbird and even on different machines and systems...

I tried to read the page source and everything seems to be there (in Firefox)?

*start of further investigation

I've been told that there is an error console for Thunderbird, so I checked it and

There is an error message complaining about line 1036 (not well-formed)...

That is:

<description><![CDATA[I'm getting a string formatted like this:  Q#b  Q#b  Q#b  Q#b  Q#b  Q#b  Q#b  Q#b  Q#b  Q#b...

**Just noticed that the special signes got ereased from my post, but you can check the link below...

***Is it possible that the problem is related to special signes of the good-old lavag site before it changed a while ago (the post is from 2005)?

Which is related to the post:

That line seems to be fine syntax to me (it's a CDATA section, so why the ****), even though we got some special chars in there.

However could anyone please explain why it is not working for me?

@Michael: Which application did you use to load the page?

I guess right now I've two options:

Hello guys, is it just me or is the RSS for LAVA Forums broken?

I didn't receive any feed for the last week and already got worried...

Check following link:

http://lavag.org/rss/forums/1-lava-forums/

For me it shows up nothing (see picture attached).

The other feeds seem to work quite fine, so I'm wondering whats going on...

I've encountered the same behaviour in LabVIEW 2011 and previous, where two projects would lock common libraries (which makes oviously sence). However I would swear that closing both projects and returning to the Getting Startet window will unlock everything (unless some VI is for some reason still running in the background). I didn't use LabVIEW 2012+ up till now, so I can't tell if there have been any changes related.

Did you check for a change in the behaviour if you close the projects in a specific order?

- open 1, open 2, close 1, close 2 -> Still locked?

- open 1, open 2, close 2, close 1 -> Still locked?

My guess is that LabVIEW does not update the locked status for common libraries in order to prevent re-checking for all libraries (which is like a reload)...

I recently used the MD-V9900 for a project. Did you already contact Keyence for that information? (They send me all neccessary information within an hour)

The documents are not on the internet and Keyence will only provide them on a request. You'll receive a mail with a link to the download information.

I could present some information, but that wouldn't help you in any way... (also because my documents are in German)

There is much more to it than just sending a string, since you must take care of a specific order when it comes to the digital interface and startup/shutdown...

My advice: contact Keyence!

Typedes must be used with great care. It is easy to store entire typedef hierarchies to a single configuration file. Once you change your typedef the data could no longer be loaded from disk (this is true for binary files and sometimes for XML files).

Searching for all 'Bundle' functions is munch more painfull than searching for a single VI.

This is how I do it:

1) If I need to add an input, I extend the existing VI and give the input a default value and make it optional (if possible) -> No changes to existing code

2) If I need to make changes that are not compatible with the existing version (new connector pane pattern, required input, VI behaviour), I create a copy of the existing VI that must be used from now on (*_V2). The old VI gets a red background and propper documentation (depricated) -> Changes to existing code only if nessecary

Notice: I provide the VIs on a seperate palette, so I can guide my collegues in that way.

I tried the XP Mode (Virtual-PC) on Windows 7 for LabVIEW 8.6 once, but the performance is very slow and sometimes a window goes missing. Now I use Virtualbox with acceptable performance. I've seperate environments for LabVIEW down to 6.1. The best choice however is a seperate installation of the required OS on real system to get access to your entire hardware.

No. Calling a dynamic dispatch will always call the most specific implementation of the method available for an object regardless of the wire type, so casting the wire to a more generic class does not change the VI which gets called at run-time. The only way to call a parent implementation of a dynamic dispatch if from within the method itself via the Call Parent Method primitive, at which point the next most specific implementation gets called. There's no way to skip implementations by design.

You're right. Should have tested it...

Well I guess you could cast your class to a more generic class (within the 'Read Trip' implementation of the child) and then call the parent class implementation of your 'Read Trip' method.

Shoot the guy whose using the German IDE

There is AFAIK no way to change the IDE- Language of LabVIEW exept for an re-installation. That is why you order your LabVIEW in a specific language.

I'm unclear on this. I've seen reference to 255.255.255.255 being also used as a "down the wire" broadcast address for example when a machine might not have an address. So the 255.255.255.255 address likely makes it past the adapter but everything I've seen so far implies the broadcast stops as soon as it hits a router. I'm going on the assumption by "router" the literature basically means any network hardware beyond an adapter since my initial test failed as soon as the devices were separated by a switch, but this is where my network knowledge starts to wear thin.

I use a switch for these kind of broadcast very often and I don't have any trouble with them... The behaviour might however change depending on your device and networking structure (I did never use the broadcast on a local network with server and such stuff...) As for the router itself I'm pretty sure they don't like to see broadcasts...

To all, is it "ok" to listen for replies on the same port as the initial broadcast? The RFC uses distinct broadcast and listening ports, I'm wondering if I should do the same?

You should use seperate ports in my opinion. I'm not very deep into networking too, but I think it's kind of 'bad style' to use the same port.

You might want to take a look into the Bootstrap Protocol which is standartized in RFC951 and quite common for such kind of tasks (at least in my business).

This protocol basically uses the UDP broadcast address 255.255.255.255 on port 64 ( I guess ) to request any compatible device. The device will respond on the
port 65 of the broadcaster. The broadcaster is then able to specify the IP-Address and some more parameters of the target device.

Besides your algorithm there is also a issue for systems since Windows VISTA where Microsoft changed some parts of the underlying networking behaviour. In my applications I commonly have a seperate network interface which I use for PLC communication on a 1ms timebase. But the system (Windows 7) could only handle ~10ms or slower.

Anyway, if you use a Windows system newer than XP, try following batch command:

netsh interface tcp set global autotuning=disabled

For me this already solved the problem...

There is no problem including external libraries, several of them, and keep them nice and tidy and separately when distributing the source (directly from the source distribution in the build). Maybe this problem only exist when distributing exe?

Yes, I was actually refering to exe files.

If I would like to implement a couple of VIs which are licensed under the LGPL for an application in my company, then I would have to build a packaged project library (PPL) in order to prevent a licensing problem. The PPL can then easily be linked as external library from the build.

This will obviously get more complex if I want to implement LGPL licensed VIs from several sources (which I can't pack into one PPL as I understand the license).

I would have no problem with the BSD license, since there is no copyleft.

Therefore the BSD license is prefered from the view of a company and for the sake of maintainable source codes.

Greetings, LogMAN

Hi Grey,

If I understood you correctly, each iteration of your loop takes 3 minutes, but you want it to be 5 minutes.

In my opinion you can just place a 'wait for next ms' next to your active code (in parallel) within your while loop and set it to 5000ms.

Greetings, LogMAN

Hi AustinCann,

You should ask the NI support if they would update the code for you (they will do for shure, if you have a support contract).

It is of couse necessary to send your code to them and you obviously need a support contract.

I don't think it is that easy to receive evaluation versions of 6.x, 7.x and 8.x, unless NI has some platform for that (which I've never seen).

Greetings, LogMAN

It appears it was "my bad" - or was it. I had a VI that extracted "all files one-by-one" instead of calling the OpenG "Expand ZIP". But I don't understand where the difference comes from (20 seconds vs X minutes). On inspection my VI didn't have any errors that would account for such a difference.

Is "Extract single file from ZIP" really that much slower?

Br, Miha

Hi mike5,

I'm not that deep in ZIP, but as far as I remember, ZIP files store their content in blocks.

If you create a large ZIP in one solid block (which is very common), it is always neccesary to extract the whole ZIP in order to get one single file.

So, for your question:

Extracting one single file is not really slower, but used on a solid ZIP, it takes the same time as extracting all at once.

If you extract 2 files one-by-one, it would take double time!

It might be much faster, if you build a ZIP with a block size of e.g.: 2MB for a huge amount of small files, so you would

be able to extract a single file in less time.

Please correct me, if I'm wrong

Greetings, LogMAN