Phillip Brooks

http://themacview.blogspot.com/2014_08_01_archive.html LabVIEW 2014, First 64-bit Version for Mac POSIX Paths This was long overdue. Paths in 32-bit are formatted in HFS Classic format. 64-bit uses the more common POSIX paths. It's mostly showing slash (/) instead of colon ( between path elements (although there is more to it than that). There is also a little bit of magic that happens in 64-bit when a path in a string is converted to a path type that allows either format, and then converts it into POSIX style. You can try this by copying the path from the 32-bit path indicator and paste it into the 64-bit indicator. Once focus leaves the indicator, the path will be converted to POSIX format (it's pretty fun to watch). This magic also happens when using the String to Path primitive. You can have a string of either format and it will convert it to a POSIX path. This makes it easier to transition between 32-bit and 64-bit as you are testing your VIs in 64-bit. Some other VIs that assist in dealing with paths between 32-bit and 64-bit are Path to Command Line String.vi and Command Line String To Path.vi inProgramming -> String -> Path/Array/String Conversion palette. These VIs are helpful in building a path that can be used in System Exec.vi or system shared libraries in a cross-platform manner. They have actually existed in LabVIEW since before 2009, but are added to the palettes now to assist in transitioning between 32-bit and 64-bit on Mac. Another path related VI that is helpful for Mac users is Executable Path To Command Line String.vi. This VI helps in getting the path to the executable in an app. This is particularly helpful writing cross platform code that will launch LabVIEW built apps, LabVIEW itself, or other GUI applications. Windows and Linux just take the path to the EXE. On Mac, the .app is really just a folder. This VI will give you a path to the executable you can call from System Exec.vi, in a cross-platform way. This VI did not make the cut for the palettes, but you can find it in vi.lib/AdvancedString.

I was traveling last week, so I didn't get to spend much time on this. While searching salesforce.com I discovered that you can override the POST method with an arbitrary method name by appending to the URL. https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm Append "?_HttpMethod=PATCH" and Bob's your uncle!

I'm trying to use the LabVIEWHTTPClient.lvlib functions to communicate with Salesforce.com I can authenticate, but my Salesforce IT guy tells me that Salesforce uses a concept called "upsert". It's update and insert combined; but I need to use the PATCH Method instead of a PUT or POST method. I can't seem to find any reference to the PATCH method. I believe the LabVIEW library uses curl under the hood. Anyone have any ideas? HEADER: HTTP/1.1 405 Method Not Allowed Date: Fri, 16 Oct 2015 19:20:35 GMT Sforce-Limit-Info: api-usage=36839/7918000 Allow: GET,HEAD,PATCH,DELETE Content-Type: application/json;charset=UTF-8 Transfer-Encoding: chunked BODY: [{"errorCode":"METHOD_NOT_ALLOWED","message":"HTTP Method 'POST' not allowed. Allowed are GET,HEAD,PATCH,DELETE"}]

When searching for a USB-RS232 adapter, look for those that use an FTDI chipset. If it has a Prolific chipset, it is probably more like epic ( fail that is ) I recall reading that the Prolific chip is often counterfeitted in China and ends up in the cheaper devices. http://stackoverflow.com/questions/32087482/how-to-diagnose-visa-rs-232-communication-failure-in-labview/32134821#32134821 I've purchased the 6' Sabrent CB-FTDI from Amazon (~$15 US) many times and never had a problem with it.

I prefer Airwolf... ( http://users.elite.net/gurpal/tv/airwolf.mid ) Convert from MIDI format? http://www.skytopia.com/project/articles/midi.html http://subsynth.sourceforge.net/midinote2freq.html

I did something similar, but no LVOOP http://forums.ni.com/t5/LabVIEW/Plink-PuTTY-works-30-of-the-time-using-System-Exec-vi/m-p/3006795#M860452

I posted an idea on the NI forums about a year ago that is long overdue; the ability to define a regex for VISA message termination. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-regex-based-termination-string-option-to-NI-VISA/idi-p/2859152 I had the idea after tinkering with a .NET library called SSH.NET. One of the methods of a stream is Expect. http://forums.ni.com/t5/LabVIEW/Plink-PuTTY-works-30-of-the-time-using-System-Exec-vi/m-p/3006795#M860452

Maybe you can use this to resolve the path? https://decibel.ni.com/content/docs/DOC-13708

Do you understand the protocol? You need to know the basics of sending vs receiving before coding your solution. Start with this... http://wiki.synchro.net/ref:xmodem#initial_handshake_rules

Sounds like a perfect use for a joystick. LabVIEW supports a joystick.

Even at 2400 baud, you should be able to easily send 10 characters in 10ms. Your requirement indicates 4 characters if we include the conditional decimal point. Add in a terminator and maybe a U16 as a message index and you should still be fine. The question is, what does the other end accept? Is it another LabVIEW app, a SCPI instrument or something like an Arduino with limited resources? LabVIEW to LabVIEW could use SI notation (%_3p) which would always be exactly 4 characters for the data. SCPI devices normally include support for scientific notation (%_3e) which would always be 7 characters in length. If you have a custom system, you will need to understand the parsing routine or capabilities in order to make the best choice. If you are writing the remote device code, simply multiply your value by 100 in LabVIEW and send the value as 00000 to 99999 and divide by 100 on the remote side.

SI notation? http://zone.ni.com/reference/en-XX/help/371361J-01/lvconcepts/format_specifier_syntax/ %_3p

A few years ago the forums experienced a database corruption and many of the attached files were lost or their links to specific posts were lost. An admin may still have some ability to search for this file, but its been a long time. I checked the OPs status and they haven't logged into LAVA in several years.

If you use the "Clean up Block Diagram Feature", the default spacing can be excessive. Look under Tools -> Options... Block Diagram and scroll to the bottom of the pane and you can experiment with various types of spacing. There is an option to adjust spacing to reduce bends in wires; I forget if it defaults to OFF or ON. If you're scrolling more than one screen up/down or left/right then you may want to consider a state machine or sub-vis.

Added to The Idea Exchange... http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Set-quot-Context-Help-quot-using-VI-Reference/idi-p/3094027

Been there, done that... https://lavag.org/topic/7328-programatic-control-of-the-context-help-window/ https://lavag.org/topic/9167-context-help-for-a-vi-without-loading/

Maybe the customer VI contains multiple event structures and becomes somehow deadlocked?

I remember using a VI Analyzer plug-in years ago to validate my driver. I'm not sure if that is now included with VI Analyzer or maybe its in the Driver Design Studio. The first thing an NI employee would likely do after receiving a driver for validation would be to test it against the requirements above using VI Analyzer. No sense submitting a driver for certification if it can't pass the automated test...

Inspiration? http://en.wikipedia.org/wiki/Category:Messenger_gods I sort of like Isimud

LV2011 is not listed as supported with Windows 8. I know that doesn't mean the code won't run, but the behavior sounds similar to a problem I saw when trying to run LV 8.6 on Windows 7. Specifically, I had UI code that responded to various events that worked fine under XP, but locked up my app under Windows 7. I think one of the events was "Application Instance Close?" This specific event might be used as an exploit by some viruses to force the close of antivirus software. Windows changes the interface and your 'unsupported' version of LabVIEW fails the OS call.

You might also want to consider a license server. It seems that you have more licenses and stations than programmers. With a name based licensing setup, you could load LabVIEW on all potential test stations and program anywhere. If you have test equipment that you need to interface to, access to a locally installed LV instance is much easier than using a remote desktop to your dev machine and Remote VISA back to the machine you are working from. The only limitation is that you can't be logged into multiple LabVIEW instances as the same user name simultaneously. In an R&D or continuous manufacturing environment, you might need to make an update to a test in situ. That may be why you have local licenses installed. With network licensing, you could log into the network, load LabVIEW, open your source code from a network location (source control assumed), make the change, compile and build. Install the new build, test and leave the station running the newly updated EXE. If your test stations are "off the network" then you've got other problems... Just checked the NI site and it looks like LV2011 does not support Windows 8. Windows 7 for business will be supported for a while, but if your company upgrades to Windows 8.x or Windows 10, you might not be able to run your LV programs reliably....