hooovahh

While I think this is the easiest solution, and probably something similar that I'll adopt, what if you only used on subVI made by one guy in your build? You are crediting a few dozen people when really it should be one guy. Could I take this to the extreme and credit every human on the planet, and then never need to worry about forgetting to credit someone?

Okay attached is a VI that can be used to parse the arguments into multiple arguments. By default the delimiter is && but another one can be provided. Saved in 2013. Parse Multiple Arguments.vi

Whatever I guess, I just assumed that you'd continue to use the JKI delimiter of >> Something like: Enable Control >> Save Button >> Exit Button Where this case "Enable Control" could enable a set of controls, but I suppose && could be used just as long as it is clear that is how this N arguments works.

Feedback on the JKI State Machine would probably be better heard on the JKI forum. As for your comments 1. I think the "Default" case could be made to exit. The only time you should see that error is during initial development, when you try to go to a case that you haven't written yet. In this case going to exit is not a bad thing because I'm going to want to stop my software anyway to fix the typo or write the case that I meant to have. 2. The JKI State Machine already has several sections, for Core, Data, Macro, UI, and even has a template category. I've seen some others add a "Decision" category and try to limit decision making to go in those types of cases. After re-reading your comment I see you are talking about cases in cases. I think this could get confusing. But honestly I have done it in the past for a group of cases that are similar like "Defer Panel" and "Undefer Panel" but really arguments could be used here.. 3. This is probably a good idea, but I'd argue that the majority of the time a case has no arguments, let alone N arguments. The extra overhead of using something like Spreadsheet String to Array on every call of Parse States seems unnecessary. I'd recommend making a subVI that just takes the scalar string of arguments, then uses Spreadsheet String to Array with the delimeter being ">>" then return the array with white space removed. Then you can call this VI in the cases where you know you entered more than one argument.

Oh good point. When I did this in the past I would actually send the error back with the reply. So if a request was made to an analog actor to read some data, it would attempt to read the data then send it back, along with the data it would send back the error generated from the attempt to read. Then the request gets the data and an error, and the error would then be handled where the request was made.

Okay so it is clear to be in accordance with the BSD license in a binary build, we need to attribute the author(s) somewhere. That can be in several forms, but the easiest to talk about is a About window. In your application you can have an about screen, and there can be a button to click or a link, which opens up and shows the detailed license information. For BSD this is required to be a copy of the BSD copyright notice, and the list of authors. This is how JKI does it with VIPM, clicking on About brings up a window where you can click Copyrights. The question that comes up is how do we easily generate a list of authors, for BSD code that is used? Certainly a pre-build on an application builder can be used to run a VI that generates this text file, which is included in the project. But with this is a few issues. First is potentially large number of files to scan. OpenG has many polymorphic types, and so using scripting to look on the front panel of every VI called looking for the copyright notice might take a decent amount of time. I think a better approach would be to include the authors associated with the package. So if you use the OpenG Tick Count (ms).vi instead of attributing just Jim Kring, and Jean-Pierre Drolet, you'd also attribute Jonathon Green, because he is associated with the package and not that particular file. In my opinion this is fine. We are attributing all authors of the module we are using which is the Time Library. If we go with this technique it would be much easier to attribute authors because you only need to scan the installed packages, and not every file called. Another potential problem is with non OpenG BSD licenses. OpenG has a standard front panel comment attributing authors but other libraries may not. But again if we decide that going with installed packages is sufficient, we can pull the author information from the spec file from each package installed. What about VIPCs, can they be used in making BSD license management easier? A VIPC is a collection of packages, that usually are associated with a specific project. VIPM pro has the feature to scan source code and create a VIPC which is the packages, and versions, that the source uses. This single VIPC file could be made for a project, and then scanned for licenses and authors, which could then create the BSD license file that needs to be included with the application. And lastly another concern is that you maybe using BSD code not installed as a package. Some LAVA Code Repository stuff is not in a package but licensed under BSD. What ever Pre-build functions that are made are going to need to support including BSD attributions that aren't just packages.

I feel like we are hijacking the thread a bit, but it is a curious topic. I've just always used OpenG, it's always been there with the huge benefit of not having to develop, test, and document functions. Of course it is possible I've been using it wrong all these years. As for attribution can't you just use the copyright notice on the whole package, and not the individual functions in them? I was thinking of writing a VI that just takes all the attributed individuals in the OpenG libraries, and making an OpenG BSD License.txt that can be included with the software documentation. But I do see the point others are making, that the effort in complying with a license, might be more work than the functions themselves. And if that is the case it is quite discouraging for the user of the library and the developers. I know OpenG has wanted to make things simpler with various license changes in the past, but what I feel would be really nice is a simple "This is what you need to do if you use OpenG in an application".

Is there a reason you don't use the Filter Error made by OpenG which accepts a scalar or array of errors to filter? This was made native in 2014, but only accepts a scalar for some reason.

Removing the block diagram is a much better solution, assuming you can live with the fact that the code will not be able to be recompiled for other versions of LabVIEW. You can edit the code linked by jcarmody to save without block diagram. Right now there is a constant for it.

Your upload is missing a file, luckily it was just a type def'd cluster and I could disconnect it to see how it worked. From your description I didn't think I'd like a design where a while loop is inside a case of an event structure, but having it be encapsulated in a reusable subVI makes me like it for some reason. I also don't like how this is polling in a while loop where an event structure could generate new events for a mouse move, but then again the refresh rate is configurable, and it is only for the time the mouse is down. A different design could be using the Limit Maximum instances of a mouse move event to 1. But then that's more work in the VI using this function, where your technique is pretty easy to incorporate into a new VI. It could be reduced even more simply by the init and close in the subVI, possibly keep the reference open with an uninitialized shift register. You can also read the calling VI reference. The result could be a single VI, that you put into a Mouse Down event, that takes care of a window move. Attached is some of these improvements. Thanks for sharing. Drag Drop Hooovahh Edit.zip

You have a couple issues. First when you read the data, all you take is the first column which is time but no amplitude. Then you use a for loop that is doing nothing to your time data, then you graph that time data on a Y axis using a Waveform Graph. To fix this take the X and Y data both as 1D arrays, then bundle them and put it on an XY graph not a Waveform Graph. Open the context help (CTRL+H) and mouse over the controls to see how to use each. Attached is an update that loads the data properly into an XY graph. ReadFromSpreadsheet1 Hooovahh Edit.vi

Glad you found the solution, but what I would have suggested, is to open Excel, then have it record a macro, then create the link manually in Excel, and then look at the text that the macro generated. The VBA code generated from a recorded macro can be translated into LabVIEW code by calling the same ActiveX calls. Some times there is difficulties in translating it, and some function calls accept various values and the macro will only show you the one way that worked. But it is a great tool for understanding what chain of calls is needed to get a function to work the way you want.

No one has ever said that.

Now that I think about it I remember a possible work around for numeric controls. While the value change doesn't get triggered for numeric control, the Numeric Text >> Text property node will return the updated value. So if the user enters "12.34" in a numeric control and hits enter, causing a value change on the key binded boolean, the value of the numeric won't have been updated yet, but by reading the Numeric Text >> Text you can find what the user entered and convert that to a floating point numeric. It sucks sure, but I think in simple cases it is easier than catching Key Down? looking for returns, focused controls, or registering user events.

Looks like you attached a lot of information, luckily by including the database, and saving the frames as default I can tell you a bit about why you are getting NaN. You told the API that the tester's ECU name is "BMS" I suspect this is incorrect because there is a second ECU in the database and it is "Tester" If you change this constant from BMS to Tester the conversion will take place and get some results. Now why is giving the ECU name important? Well it doesn't have to be. If you remove the Get TX and RX Signals VI and replace it with a constant 1D array of string with the signals you want to convert everything should be fine. But what is happening right now is you are telling the API that you want to convert all the signals that the BMS expects to receive. The problem is you are actually getting BSM data and you want to convert all the signals it transmits instead. Another way of looking at it is you are asking to convert frames with ID 0x520, but in the frames to convert that frame is never seen, so when you say what is the value for BMU_Alive_Hil, the conversion says that there is no value for that signal. Also you are forgetting the Close Conversion VI at the end after the while loop which cleans up the opened references. And you can remove the old and busted way of doing frame conversion.

Topic moved, next time feel free to use the Report To Moderator feature. It will get more visibility that way.

When using a string control the easy solution is to right click and enable "Update While Typing" which will trigger a value change with every key stroke. Then hitting return for the key binding on the button will still have the last typed char on the string control. Other controls don't have this problem as often, because if I tab into a enum, pressing up or down, triggers the value change and should be fine. There are other controls that there isn't an easy workaround like this. One case is like with a VISA Resource name. If the user tabs into the control, and types COM0 then hits return, then the value change won't be triggered, and because it isn't a string, there is no update while typing like a string.

Yes sorry if that wasn't clear. The API I wrote is just intended to facilitate the conversion, but the actual communication is done by what ever your hardware has available for you. In the past I've used some cheap CAN devices like a RS-232 to CAN converter. Here there were a set of VIs to get and set frames and they worked fine. Using the conversion API meant there was some option to convert to signals, from a database, that the user could load from a file on disk instead of hard coding it.

So I've never done this exactly as you need, but I have loaded simulink models into Veristand, and prototyped using these compiled model in LabVIEW using the Model Interface Toolkit. Here's a few links. http://digital.ni.com/public.nsf/allkb/0DCC5D6CFFBED96886257DFE00626859 http://zone.ni.com/reference/en-XX/help/374160A-01/vsmithelp/mit_convert_model_to_dll/ I don't know the full workflow, but you could have a user load a .m file in your software, which runs command line tools which compiles it to a DLL that can be loaded with this toolkit. Probably a decent amount of work. Or maybe it is an option to have the full LabVIEW development environment on this PC where you could perform scripting to make the Mathscript node, import the .m file, and save it as a VI that is then loaded into your EXE. No idea if importing a .m is exposed as a scripting method or not.

That sounds like a good idea exchange. The times I could think of using this for sure is on the defer front panel property node. There have been times when I would defer the front panel, do some operation, then undefer. If an error was generated during the "do some operation" part then an error goes into the undefer property node, and nothing happens. I've since wrote my own wrapper around this function that adds some other features and still undefers on error, then merges them together for this reason. Ouch, good to know but NI (and all developers) should really try to perform closing operations even if an error is passed in. I've never seen it as a written rule but it seems like a good best practice.

You must know there are many options for emulating old DOS games on various video game consoles, and most easily a PC. Still for $9, do what you want with it I guess. That's partially why Arduinos are often used for things that discrete components could do, they are so cheap and easy to use, just put them in everything. As for LabVIEW, so it is running a desktop version of Linux, on an ARM Cortex A8 processor. Does that mean the standard Linux version of LabVIEW can be installed and ran on it? I'm guessing it was designed to only run on x86 based processors so no. Another very cool possibility is installing the NI Real-time Linux OS. The MyRIO is running on an ARM Cortex A9 processor. No idea how compatible compiled binaries are between these families but it would be cool to install NI's Linux OS on this hardware. Then it might be possible to deploy embedded LabVIEW code to it. Of course there is no FPGA like the MyRIO, and I'm guessing there would need to be a ton of work to expose things like the I/O of this device, probably call library nodes. And the Linux kernel would probably need to be modified to have access to the other available hardware. And even then there might be some things that just don't work, because NI probably doesn't want their software running on non-authorized hardware. At that point why buy NI hardware at all right? (just kidding I love NI support and all it comes with). But being able to buy a $9 embedded piece of hardware that LabVIEW can be deployed to is a very cool concept.

If you read my link I mention that the XNet conversion library works on non XNet hardware, and can be used to convert an array of frames to signals and signals to an array of frame without needing any hardware. This library can work with your hardware when used properly. Oh and the example is just meant to show that you can get all TX and RX signals from a DBC, but you can also replace it with a constant of the signals you want to be able to convert.

Yeah I know what you mean, I listened to the same Kesha song for far too long, which was about 30 seconds . Yeah I'll pull out that one window on its own, then not minimize it but put other windows on top and it keeps playing. It is some kind of limitation with chrome windows that lose priority.

So the good news is it looks like you are on the right track. You already realize you can't use the channel API with that low cost hardware. So you have to do the conversion your self and it seems you found the old conversion library. It is recommended that you use the XNet conversion library instead. The old library has some known bugs and is several years old. I'm guessing since XNet can do the same conversion that they won't be releasing new versions of it. So if you want you can try out my conversion library, which wraps the XNet conversion API. https://decibel.ni.com/content/docs/DOC-39793 In the example it shows how to take a DBC, and create frames from signals, and then take those signals and turn them back into frames. Also know that NI has a subforum for automotive questions like CAN, you may get more help there. http://forums.ni.com/t5/Automotive-and-Embedded-Networks/bd-p/30

Oh that is a much better solution, go with that.