hooovahh

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.

WinAPI still works in Windows 7 and even 64 bit. I've kept an updated version, and haven't found a function that hasn't worked properly yet, but admittedly I don't use every function. If it ran for weeks with no problem, then crashed twice in one day I wouldn't think memory leaks either. What about the system log? Windows has an Event log built in which keeps track of crashes, blue screens, and other system level issues. http://www.sevenforums.com/tutorials/226084-event-viewer-open-use-windows-7-a.html Looking at that I'd suggest trying to find what changed between it working and not working. The obvious things is installing or uninstalling software and drivers, or Windows updates.

Crash files are usually not very useful, sending it to NI is the only way to get useful information out of it and even then it might not tell you anything. http://digital.ni.com/public.nsf/allkb/7E9EBE4CA3B6DCE786257633005E7121 http://digital.ni.com/public.nsf/allkb/2FF01AD2F6A02ABD862578D40053FCC7 I haven't seen any watchdog examples for Windows host applications but sure it can be done. Using the WinAPI you can query what applications are currently running. Just poll that every so often and see if your program is no longer running. A more useful debug concept, could be to log the states of a state machine to a text file like a heap. Then if a crash happens you can at least see what lead up to the crash. This will cause a slow down in the application as logging is done, and the file might become giant for long running applications. Also have you looked at memory usage? Is it stable? Many applications that crash after days of running are caused by accidentally opening references without closing, or having arrays that grow in size forever. Various tools can help determine if memory is stable, some built into Windows like Performance Monitor, and others by NI like the Desktop Execution Trace toolkit.

I don't want to live on this planet anymore. But seriously I find it so difficult to hold back emotions, when topics that I feel I am an expert on, are so misunderstood. And LabVIEW is often times misunderstood.

NI would likely say some marketing statement about how the maker movement is an important to them and they hope this fills a gap between student, and advanced users. The strange thing to me is that in the past (I'm still looking for the link) I've seen NI employees state that a "Student" is someone who takes an interest in a particular subject. And that the student edition would apply to anyone looking to learn. This is somewhat supported by the fact that the student edition was available for years up at Sparkfun which required no proof of enrollment in formal high level education. I never went through the full process but I assumed the same thing when applying for the 6 month free license. Although it is sorta funny to see NI people dance around answering this when they aren't lawyers. http://forums.ni.com/t5/LabVIEW/Who-is-eligible-to-use-the-Labview-8-student-edition/td-p/415471 After some back and forth the OP asked the question as straight forward as possible and the NI employee answered with: They did not say you cannot buy it, or that it would be illegal to buy it, just that they wouldn't have the proper usage rights. Anyway, there's been enough chatter about this Home edition lately that I believe there is individuals who will buy it. There was once an idea exchange for it that had a bunch of attention too.