hooovahh

LINX now is supported on commercial applications starting in 2020 BTW. Your opinion is valid, and you have reasons for it, but I think it might be a bit of forest from the trees situation here. LabVIEW tends to have a one or two major bullet points of new features with each release, with many smaller improvements that are less noteworthy. Some of these aren't very applicable to me and I don't see the benefit of the update, but I can still recognize that a bunch of effort was put into a making it into the release, and makes me think NI isn't sitting idle. I know I made a list like this in the past when a similar topic has come up but I'm having a hard time finding it. 2012 - Loop Tunnel improvements with concatenating, conditional, indexing, and last value / Project Templates 2013 - Improved Web Services / WebDav / SMTP / Bookmark Manager 2014 - Actor Framework (I might be off by a version or two) / 64 bit Mac and Linux support 2015 - Custom Right Click Framework 2016 - Channel Wires 2017 - VIMs / Forward Compatible Runtime 2018 - Command Line Interface / Python integration / Type Specialized Structure for Improved VIMs 2019 - Sets and Maps 2020 - Interfaces for classes / Free Community Edition with Application Builder And here are a few of my favorite features that I can't remember what version they were added. Error Ring, Improved VI calling under Application Control for starting asynchronous processes and static VI references, DVRs, Conditional Disables based on environment or Project variables, Linux Real-time operating system, allowing for 3rd party and open source tools to be installed and called with the System Exec, and then adding an embedded HMI, User Events, LINX toolkit for running LabVIEW VIs natively on a Raspberry Pi, or controlling an Arduino connected to the host, QuickDrop's plugin system allowing for all kinds of tools, filtering on search results, improved performance of tree and listbox controls, NIPM, and loads or more scripting functions with more added with each version. I sure hope LabVIEW has a future because I've hitched my career to it. But even if NI closed its doors tomorrow I feel like I'd still be using it for another 10 years or so, or until it didn't run on any supported version of Windows. But I feel your concern, and if I were a junior engineer starting out, I would feel safer in another language.

Oh boy 2006, I think that predates the LAVA 1.0 migration issues, and then several other newer revamps. I certainly don't have this, and have no way of getting something so old. I can contact Michael if you'd like.

Not sure if you are past this point or not, but be sure and take a VM snapshot at some point. Having a fresh VM for a semi-standard environment like LabVIEW 2017 SP1 with DAQmx, Vision, RT (or whatever is common for your industry) is super useful. Taking this another step you can have a snapshot for each project too. Sharing this with team members can be a pain, so I generally just go through this process at the end, or near the end of a project, then archive the VM somewhere on the network for safe keeping.

I think combining that what PiDi gave, with a single column listbox, and an event structure that gets triggered on the Double Click, event would get you most of the way there. You can also try to capture a <CTRL> + G on the OS to go to the next. I think the Initialize Keyboard an Acquire input would work.

Okay this is possible, but it may need extra work when making the file. TDMS data in channels by themselves are just 1D data. They have no way of knowing how much time is between each sample, or the start time. But you can write to the properties of a TDMS channel, and put in extra information like the start time, and time between samples. This works great for things like the Waveform data type, and when you write this data type to a channel, these properties are already written. So you can read the start time property, the dT (time between samples), and the number of samples in a channel (property automatically written), and with this information you could make a slider where the user selects what section of data you want to load. You would have to convert the sliders input, in the number of samples to read, and the offset of the read, but that can be done based on the sample rate. If your data isn't being written at a consistent rate, you can also have a separate channel that is Time. Then you can read the first sample and know the start time, and read the last and get the end time. Intelligently grabbing just the data you want would likely take some kind of binary search but would be faster than reading all samples, when the channel contains lots of data. This requires that when you write the channels samples, that you also are writing the samples time data. These two channels will need to have the exact same number of samples. There are a few options, and all of them go outside of this toolkits functionality.

I like TestStand but it is the one size fits all type of software. NI can't know what you'll prioritize in features in a sequencer and so it either has too few features and only can satisfy the simplest of projects, or it has everything thrown at it, in which case there are parts almost no one will use, and it might have a steep learning curve. That's why one of the justifications I agree with when it comes to a home grown sequencer, is that you know the types of features you need, and the types you don't. Now obviously requirements change, and you need to change with them, but high level things you know you won't use, can help trim the feature set in replacing TestStand. For me the custom sequencer grew out of the need to have it run completely on RT. The Windows application is just there to for starting the test, status, final report generation, and manual control. I've used PTP Sequencer in the past, and it was pretty basic and not really a TestStand replacement. But it was helpful in getting some ideas on where I wanted our sequencer to go. It wasn't open source and I still don't think it is. As for cost savings. All the analysis I've seen has favored TestStand when it comes to cost of developing your own.

I downloaded everything here just fine.

Good discussions are timeless. There's lots of great content on LAVA that goes dormant, but its still there. I would almost put XControls in the best features, and worst features list personally. I still stand by my debugging comment from almost 11 years ago.

A seemly highly specialized piece of equipment can usually justify the price. But not meeting your needs and costing that much seems crazy. It gets me wondering if there are products NI offers that over the life of the product never sell a single unit. Years ago I was in a hands on session with some PXI card NI was selling that allowed for taking many temperature readings, by using fiber optics. Something like the fiber optic had microscopic cuts in it that allowed for taking many channels of temperature reading, like on the order of 100s. I looked up the card and I can't remember the price but I thought it was like $20k or something. I figured no one would use this but looking online it seems people did, but it has now since been obsolete.

Not that I know of. I'm not sure if this is an option for you or not, but you could completely shutdown the LinuxRT device, then have power removed, then reapply power. I believe the bios of these controllers allow for wake on power being provided, and your app can be ran on startup. So maybe have some kind of external device work like a watch dog. While your program is running keep hitting the watchdog, then when your program shuts down the timer starts counting down, removes power, waits a second, then applies power again. Just a thought and probably not a great solution, and someone with more Linux experience may have better suggestions.

Here is a discussion about it on LAVA. If this is on Windows I'd suggest trying a different compression tool like 7zip or the native zip to see if it will work for you.

I have seen bad DBCs in the past. But in those cases I would just load it up in XNet Database Editor, re-export it, and then it was fine. I haven't seen it not load in XNet before.

Oh man and I was just touting NI support as being one of the few "fine" parts of NI.com. Never mind. I'm really confused and I think the report a bug feature is worst than you made it sound. So I got there and it says "In which product did you encounter the bug". It asks for a Serial Number. I enter "LabVIEW" or "LabVIEW 2020" and it didn't work. So I tried entering the serial number of my hardware or model number and that didn't work. I think I'm supposed to put in the serial number of my LabVIEW license, but I'm on a disconnected license from a VLM so I have no serial. Am I not allowed to report bugs? I'm thinking I'll make another post on the dark side to try to get some kind of answers. EDIT: Okay it seems I can find my license number but I need to dig into the quote to find it. I couldn't find it anywhere else.

Very neat thanks for the background on a toolkit I didn't know existed. I'm sure NI was in a "damned if you do/damned if you don't" situation, but this can be seen as another example of NI's first party solution, stifling 3rd party toolkits. Also I generally don't mind bundling in stand alone binaries in cases like this if it means an easier experience for users, similar to bundling in the SQLite DLL in the build.

You have to create a free NI account, and login with that. Once logged in and connected to the internet it should activate. If you have any problems with activation you can try contacting NI, or post on their forums.

The LabVIEW Wiki has lots of content. I usually recommend new developers checkout the Getting Started or the Online Training sections.

The problem is sometimes the compiler gets a bit too aggressive and does something that it thinks won't functionally change the code, but does. Like what if the compiler mistakenly thinks the close reference function can't be called? Well it will think that node can safely be removed and nothing will change. But if the close was actually being called in the IDE, and now it isn't in the RTE that could be a problem. The Always Copy function has been known as a band-aid because it forces the compiler in some cases to leave things alone instead of trying to optimize code. This would then have the code no longer leaking memory. It seems to be a real bug, and NI should fix it. But in the mean time you might want to sprinkle in some Always Copies and see if anything changes. IMAQ images are references and so I don't know if it will actually help or not. I don't have vision to test with.

I'm also a fan of SVN. For multideveloper work we use VisualSVN Server. The free version does a great job, but the paid version has domain integration among other enterprise features. I'm not sure what can be used to make a local repo. Jim had an old blog post years ago that I can't seem to find. The client side I just use the explorer integration that comes with Tortoise SVN. There are LabVIEW toolkits that add quick drop, or tools menu, and project integration, but none of them worked with our work flow enough. Here is the first package I found made by JKI that does some of this. I know ViewPoint also had one. Here is Nancy talking about some of its features. Oh and there are two paradigms when it comes to SCC. One is Lock/Commit, and the other is Merge. A single developer shouldn't need to worry about it (unless you are on multiple computers). But I configure SVN to be Lock/Commit. This means only one developer at a time can be editing a file. You can break the lock, but then you may have two version of the file and then need to figure out how to merge them. Locking helps avoid that. When a developer is working on a subset of code, and no one else should be touching it, this works just fine. But at some point someone may need to lock the whole project to update some large part of the code, and that is when going around and being like "Hey Brian can you unlock this I need it" would happen.

Adding to crossrulz suggestion. If you do want simple I2C or SPI, using an Arduino is a great solution in LabVIEW. NI has their LINX toolkit, which downloads a known set of firmware to the Arduino, and then in LabVIEW you have the LINX palette which basically tells the microcontroller to execute some set of steps. These commands are just serial commands, and when plugged into USB should appear as a normal VISA device in LabVIEW. I don't have a pharlap system to test with but with other remote devices I've used they just get enumerated when they are plugged in. I personally have not used pharlap much and am unaware of the difficulties getting that hardware working on it.

If you are just trying to replay the message you already have from a valid log you can do that and see if the ECU is happy. Was it possible that it was setting DTCs when the log was recorded? If you want to change any bit inside the payload you'll need to figure out the algorithm used. As we said it clearly isn't the standard one used for CAN. Other than just guessing a bunch of things I don't think you'll be able to get past this issue. That is again unless all you want to do is replay a already recorded log. Also here's a random thought. Are you sure that byte is a CRC at all? I mean the values you gave in your example all were 0xF_ or 0xE_. Do you have the DBC that these messages belong to? It doesn't match the standard CRC, and there is a counter after the CRC which I've also never heard of. If it is a CRC I'd expect it to have a somewhat normal distribution among the 256 possible values. Does the rest of the log reflect this? EDIT: I'm convinced that is not a CRC. You have two frames each with 0xF9 but the payload is different. Statistically that isn't likely to happen often.

I don't think so, it won't work outside of a project anyway since that conditional value is only going to be available in a project that has that value.

I've seen that some cases the symbols shown are only pulled in from the target that is listed under the project. Did you happen to open this from a blank VI or a new project? Anyone can add additional symbols, and NI adds a few when you add certain targets to your project. You can view these by going to the properties of the target from the project.

Yeah what Rolf said. I've seen several CAN payloads with a message counter, and CRC, and never has there been any meaningful data after the CRC. I have seen times when it is an 8 byte payload, and the 7th byte is the CRC. But in this case the 8th byte wasn't used in the CRC calculation. You can find the typical J1850 CRC calculation online here just set the Predefined to CRC8_SAE_J1850. After playing around for a little while I couldn't get the CRC byte you provided to match. If you do ever figure out the algorithm, there are a couple of options on how to do this in XNet. Obviously every frame will have a different counter value, and different CRC, so you can't use a single point session. You can make a loop waiting for some amount of time to go by, and then send a single frame, then wait more time and then single frame again. This is going to be software timed and the jitter will likely be large, and depending on the amount of frames this can put extra work on the CPU just waiting and sending single frames as fast as possible. In XNet this will be the Frame Out Stream session type. An alternative to this is the Frame Out Queued session type which allows you to pile up frames to go out one at a time, using the timing from a database. Here I called this the bucket filling technique since you need to make sure the queue doesn't go empty. And lastly, NI does offer to load up some very basic C code on the XNet hardware, which allows for modifying the frame's data before being sent out. This is undocumented, experimental, and only useful if you actually are using a standard CRC. Otherwise you'll need to write your own C code, and that gets even more difficult. I'm only mentioning this feature to be complete, and am not actually advocating you use it.

How about something with the File IO? Maybe copy all files and folders from one location to another and list the files that were new or overwritten? Maybe open a text file with times and values in it then graph it? Maybe import a text file into a table and color the values that are greater than some value red, and lower than some value green?

So one thing that might help make it click, is that objects aren't reference based by default. So you are initializing an object, adding an axis, and then passing that data into a loop. The data that the loop uses each iteration, does not change it is the same data over and over again. However if inside that data is a reference to something, then that something can change, and the reference doesn't. But that feature is only used if the developer of the class used references in the private data of the object. The class data can be thought of as a cluster (because it is). So imagine if you weren't using an object, and were just using a cluster. Would passing in that same cluster to the loop do anything different? Well if a reference was in that cluster then sure you could write to the reference in the loop, and then the next iteration would have a different value in the reference if you read it. But if in the cluster is just normal data types like string, numeric, boolean, etc. then it doesn't matter if you are updating that cluster in the loop because the same value is passed in each time. What Antoine was suggesting was to use a shift register which passes data from one iteration of a loop, to the next.