Benoit

Dear Jon,

You were talking about the bug tracking. In deed, it would be very helpful for us, developers that makes promises to our boss and customer, to know when the bug are planned to be resolved. Per example the bug  493662  concerning the .net is causing problem to a lot of us. Listing a work around to use external .dll is a killer for LabVIEW reputation. and this bug is there since 2014... I personally believe that new features should be delayed till all the bug are fixed. All LabVIEW developer will be so happy to not encounter bugs that kills their planning.

So please fight fur us and represent us in front of NI to push them the importance to release a version of LabVIEW without bug.

Benoit

I think it is not related to this tread. please start new tread.

Please be more specific when asking for support so we can help you.

Benoit

I wish so much to be in direct contact with NI team development... Or be part of the team that addresses the issues. there is some that are in the bug list since over 8 years and the work around is do not use LabVIEW use something else to do it... like .net issues per examples.

Is someone talk to them about Agile development?

Sometime new feature need to be postpone in order to fix the old sh*t that are blocking point.

Looks like the marketing has to much power.

Please be stable then add new feature that people ask... not the one that just look great and kill the CPU... 

Just some though...

Benoit

Hi everyone,

I am struggling in one weird behaviors concerning .net in LabVIEW.

 Why as the picture bellow show, I cannot select the method of compression/decompression?

In LabVIEW 2011 this method works as expected. It seems that the constructor changed since the old .net. but for some reason, I cannot decompress any string with any software I did with my LabVIEW 2017.

Anyone know how to do that or understand what is going on?

PLEASE!!! do not suggest me external tools. this is a requirements to use the native .net in Windows 10... Security reason... I cannot use external .dll and I have a s**t load of data in our database that cannot be accesses anymore. So I need to use the native .net.

Thanks everyone for your support.

Benoit

In some cases B is useful like said previously in case structure. especially when type def constant are used and over lap the error and other wire.

cosmetic, but code readability is not only cosmetic.

OK... but it's like using global variables... It's not very standard. and can be quite difficult to know where it comes from. If you put it in a sub vi, even this sub vi is doing nothing... I think it would be better.

Try this:

It is like magic. Since it is a strictly type reference, It will be included in your build. if it's a GUI, set the windows Appearance like you want.

go try this: 

Great suggestion... I'll try something.

Are you new to electronics to? if not, do with labview the same way you will do with electronic component.

OR if i understand well, just create an array of element with the same dimension of your original sine wave. In this array add random value centered of not to 0. then add the two array and display it in graph to see the results.

Benoit

I don't know if it's applying to you project, but in my case, I have different .exe with different responsibility that talk with each other trough VI server.

This allow me to be very modular and when I have an update, only the required module is recompiled.

Some process that are used for multiple other .exe, I load them as service in Windows.

Just saying... that could be useful 

Benoit

For the original post,

Instead of doing a mass compile on the huge project, try to do object by object. I have a feeling that only one object is causing issue for you.

Also, are you trying to do that on a new PC or on the upgraded PC that still have the old LabVIEW version?

In my case, It happened to me because of a .dll. External code some times creates problem.

Benoit

Well... it's my design that I did for a company... Cannot sell it... but my value is high. 

Benoit

For my part, I hate TS for the license cost and for it's advantage that is an inconvenient for me. TS is so capable to integrate anything that it becomes not user friendly. The knowledge ramp is quite hard. Doing things in parallel is not intuitive and if you want a good GUI for your operator that is multiple language... GOOD LUCK. In a manufacture context, time and clarity of instruction counts.

I create my own test framework that integrate database, debug tools, instrument command spy and overpass functionality. Everything has a "secret" backdoor to connect to the tester to see what's going on. (I  VI server) I developed a HAL "Hardware abstraction layer" level that allow the technician to change any instrument in a matter of minutes and this is 100% transparent for any test sequence that runs. Per example I support over 15 different power supply (serial, GPIB and USB). (plug it and play) I also integrated Domain login capability and so much more. Did I said that it support batch mode, single mode and asynchronous mode for unlimited test position as well as debug step by step? 

Finally, developing a test sequence with medium complexity (CAN, SPI, I2C, Ethernet, ARINC,+ instrument power supply switch, DAQ, Oscilloscope, camera (bar-code and vision inspection) and more, about 250 measurements take less than a week including deployment and validation. TS cannot offer that.

In other words, if you want all those functionality in TestStand, you need to develop them outside TestStand. Training someone on older code made in TestStand is way too long. So a huge license cost just to execute test step no thanks not for me.

By the way... I'm working for an important electronic manufacturer... High volume!!! No TestStand and happy about it.

It's coming very soon.

I am completing the integration phase this week, therefore it will be tested.

Only the SPI version not validated, but it should work.

Give me one more week.

Think 32 bit vs 64 bit.

.net will always use the correct architecture. Custom library that has been developed externally, can create a security breach as well.... .dll .ocx....

Native .net that you code yourself would be must trustworthy. But be aware that you need to make sure that the .net version used will always be compatible with the latest .net updates... sometimes it creates issues. this is likely less possible with external code if they are not relying on interpreter (java .net C++ or python.)

Another case would be licensing. When you use someone else code, be sure the licensing allow you to use it in your situation.

A wrapper will give him the same situation and create another unnecessary layer.

Did you know that a Cluster is what you are looking for? in your case, it will be two cluster into another one.

You can create your own header file (.h) and import your .dll into LabVIEW. That would be much better solution

Note that the UINT is a separate parameter.

Of course it is possible. National vision library will be helpful in this case. if you do not want to pay extra$$$ per station deployed, you can use OpenCV and create your own wrapper.

Try it by yourself. it's depend of your adapter. This VI use the friendly name that is usually a copy of what is seen in the DEVICE MANAGER.

Indeed, if you never connect the cable, it will crash.

I have now move away from ftdi. I found a much better solution.

Microchip MCP2221A Also a version for SPI is available.

Amazing IC with a lot more capability for a fraction of the price. We develop our own PCB to interface it and it still become cheaper that the cable from FTDI.