JamesMc86

No I ask, I haven't seen these before and you have given no description

What do they allow you to do?

Maybe for efficiency you can use both. First look for some common causes e.g. Floating point maths on FPGA which will rule out most things but it would be difficult to catch everything (for FPGA I bet this could catch 99% between using floating point, using non fixed arrays and not using the call library node.). Then do the test opening it on the target, if it is not broken it is compatible, if it is broken you can flag that file as inconclusive and highlight the VI which is broken. The harder one is actually RT I think because there are not many specific functions that make it broken under RT, it is more of a code style that needs to be considered. in fact the only things I can think of right now is if you are calling a dll and need a .out for VxWorks and if you are using front panel property nodes (but these won't break the VI, they just don't function when built) so this is pretty tough. If I was approaching this I would be tempted to make VI analyser tests for common compatibility issues to make it easy to run. You may not catch everything, but you can rule out a lot.

Hey Rolfk,My comment wasn't intended like that. That is a good recommendation, I was just building on it.

How/Why would a image be invalid? If the reference could be invalid then Rolfk's response is a good start. There is are image info function that gives you the size and the type (RGB, U8 grayscale etc.) if that is the issue. (IMAQ GetImageInfo is the function). If image content is the issue then you get a little harder, but guessing it will be one of the first two if the functions throw errors.

Hey, I replicated the issue and I think it is a bug as it works fine using flatten/unflatten directly or in a cluster. I filed a CAR with R&D under ID 398196 Cheers, James

The issue is actually not related to OOP. The error I see is related to the references within the object. It is illegal to use these on a shift register as it allows the potential for it to be changed but its value must be resolved at compile time. If you create a shift register then wire a reference too it then it will normally break the VI immediately. Obviously an issue here is that the compiler doesn't resolve this in an object until code generation, it would be useful if you can specify these as invariant somehow, possibly the ideas exchange as it is intended behaviour, but it does limit what the objects can do. Cheers, James

What is the source of the files? I have not come across them before. Even if no-one has existing code for them, if the structure is published it should be possible to write a parser in LabVIEW using the binary or ASCII file palette.

I hate to be negative but I suspect this is not possible. My reasoning is that g code is g code. It only breaks once you try and compile it for a particular target which requires opening it in the correct context. I guess the defining characteristic is that the unsupported functions could mostly be summarised in a few rules. E.g. Anything using a dbl data type can't run on FPGA, I bet using scripting you could rule most VIs out of fpga execution pretty quickly. RT is harder as the differences are more subtle. I suspect this may all end up being slower though. Cheers,James

Many people I know actually still run LabVIEW for Windows in parallels instead of transitioning. The main benefit being that most/possibly all tool kits don't support LabVIEW for Mac so you are limited to core functionality. This maybe fine for you but wanted to make you aware you maybe able to avoid this. The flip side is I have never seen anything to say we officially support this configuration but I have seen many people using it successfully (including NI staff).

Hi Erik,Thanks for sharing your experience. It is interesting to hear about Git as I reached a similar conclusion. The windows clients all had some holes in them and I got to the point where without a clear benefit to the technology, mercurial was simply easier to install, configure and use for Windows & LabVIEW.Cheers,James

Hi Flinstone, The cause does appear to be a bug, what version of LabVIEW are you on? I found a CAR (128114) which appears to be the problem where the bit file is storing an absolute path to the type def instead of a relative path. Unfortunately this would either mean upgrading to 2012 or keeping the disk hierarchy in the same location on both machines. I guess a third option would be to disconnect the type definitions for the final build. Cheers, James

MCornwall is right (and has some great links). The X Series do have some additional timing engines now vs the older cards but because they are still typically multiplexed cards the ADC is already in use and cannot be used twice. Cheers, James

Hi, You should use the open reference in the same way. LabVIEW has some check that the running bitfile matches what the code expects (I am not sure exactly how but I think there is a checksum involved). The one thing to be aware of that if LabVIEW tries to run the VI again and it is already running it will spit out a warning. Cheers, James

Your understanding about structures is correct so something else is at play. How do you know about this update? If it is from probes is the CPU usage high? I have seen this cause probes to report some strange things from RT targets. Alternatively a code example would certainly help!

That is fundamentally not the way copyright works! All software you write is covered by copy right as soon as you write it whether you write any copyright notice or not. By default this means anyone else cannot use it. A license attached then permits you to use it where copyright would have prevented you. It all comes back to copyright law. Now if you find a piece of software in the wild with no license, no author details then it is probably very hard for the author to prove it is his and defend the case but that doesn't necessarily make it right. (That is not to say I disagree with your point, if it is out there without a license that is probably the way the author intended it to be used, but legally there is no right there)

It was certainly still working as of 2011 as I saw someone pulling in emf I believe. I think in that case the whole image scales though, I am not aware of any format where different elements scale at different rates. Quick google suggests it is the components which are important. Can't open the VI yet but look at this thread http://lavag.org/topic/3085-custom-controls-custom-decorations/

Why would you even bother asking? You can pull in any image as a decoration anyway

I seem to think I got a similar comment on mine using the same sort of technique though previous comments on here suggested the OOP is acceptable for the CLA, just apparently not useful design patterns! Still passed so can't complain.

You could share it with NI and help everyone that uses the feature, you would probably help more people! Well I don't think anyone you help is exactly going to go trying to get you in trouble are they. But then it might not be their software and then you are aiding IP theft. As I say, I don't know exactly what could happen but I'd say there are as many people who stand to get hurt from it as benefit, just because you say you would be ethical with it, I've heard there are some unscrupulous folk on this Internet (though I don't believe there are many wandering the LAVA corner of the net)

Whilst I agree in principle that no harm is done there is a reason why they have password protected it and you have therefore gone against their wishes without know why they have put the password on. It is also hard to prove if you work on something similar that you have not taken inspiration from their IP (and there is little legal protection against this I believe). There is a reason why we have curtains on our bedroom windows I can't speak on behalf of the organisation regarding what would happen if you posted it, but it would certainly appear to be in breach of your license: As for the consequences I don't know exaclty, presumably you could be at risk of being sued, especially for disseminating the information. If your employer owns the license they probably wouldn't be to impressed!

The other thing to consider is, right or wrong, there are a number of people using this feature out there already. (I don't know numbers or anything but I have certainly seen it). I don't think they would be impressed in NI turned around and said its been compromised but we aren't going to attempt to improve the protection you are using on your IP. I do always recommend removing the diagram if it is highly sensitive though.