hooovahh

Oh sorry I didn't read your post closely enough. I don't know how to do that.

I think what you want is MoveBlock. This is basically a function that takes a pointer and returns the actual data at the pointer. I don't deal with DLL calling often, and I have a hard time figuring out things so I might be wrong.  You may want to do some research into it.  Here are a few links.

4 hours ago, Mads said:

I agree, with the former😉 It is time to pause the planning to redecorate the kitchen when there is a fire in the living room (no matter how fire retardent the new paint is going to be).

We are at the whim of the city planners to approve of the use of the fire extinguisher...okay the analogy falls apart a bit there.

I do occasionally have correspondence with him. He is aware of the spam issue and we've talked about turning on content approval. He seems to want to update the forums and just has limited bandwidth to do so. Until that happens I'll just keep cleaning up the spam that gets through.

1 hour ago, Novgorod said:

Of course you're right, it should be sufficient in almost all use cases to simply use the provided vi.lib version. It's more a curiosity thing and also a neat trick to have very compact portable tools. For example, the built-in zip/deflate/inflate functions eliminate the need for external dlls, since (to my knowledge) there is no pure G code zip implementation, but that's a story for another thread.

I did try to implement inflate/deflate in pure G.  There was a website that explained in pretty easy to understand english how the compression works, and gave example code on how to implement it.  I went through it step by step but it still wasn't producing the correct data.  After trying in my free time for a bit I gave up. I thought it would be helpful on Linux RT for web server stuff where it could make PNG compressed images. There are alternatives.

It's just every morning sorry. I was getting emails when reports came in. This made it easy to review them from my phone as they came in but that broke some time last year.  So now I need to check the site for spam, or reported content.

I don't have that feature available to me. I'll mention it to the admin.

5 hours ago, ShaunR said:

By now, you really shouldn't have to be deleting them manually.

Moderator tools are way more restrictive than Administrator.  I appreciate the support but it is all I can do to get rid of the stuff manually that makes it through until better tools are installed or upgraded.

Also just so others know, you don't have to report every post and message by a user.  When I ban an account it deletes all of their content so just bringing attention to one of the spam posts is good enough to trigger the manual intervention.

Honestly my tools for fighting this are quite limited at the moment.  That's why upgrades are likely to come.  Until then thanks for your patients.  I also check the Unread Content section and hate it to see it blasted with 100s of garbage.  When I'm at work it is easy to just refresh once in a while and delete it as it comes. But then Brian goes to sleep, and robots don't need sleep.  Maybe the next upgrade will be if I can become a robot.

Yeah it sure has. It has slowed down believe it or not. But I do still see new accounts being made.  I'll just keep trying to flag spam as I see it, until new upgrades are complete.

I only worked with an FPGA CAN device once, and it was a long time ago.  For me there was an example that showed how to create a DMA on the FPGA to send raw data back on.  Then on the host you could read or write the raw CAN frames.  From there you could use my frame signal conversion library.  But I've never used them on the sbRIO so I'm unsure how that process is different.  I'd be surprised if there wasn't some kind of CAN example installed with the software. From LabVIEW go to Help >> Find Examples and then search.  I suspect the CAN port won't show up in MAX. To use it you need to write code, or open an example.

This looks interesting. What are the licensing used?  What are the restrictions?  Is there a manual that is in English?  Is the source code available?

So I use Inno Setup for making most of my LabVIEW installers.  It is pretty easy to setup file association with the registry like the LabVIEW Wiki mentioned.  Here is a post explaining some of the settings.  Once I'm on the LabVIEW side I've always used the property node Application >> Command Line Arguments. Maybe I've just used that because the event didn't always exist?  I'd like to think the property node gives you more control since I can send other command line arguments not just a file. But the majority of the time I do just want the file path.

Yeah I get this. We also have Intrepid, and ETAS in the mix along with other random serial to CAN converters. It can be a bit of a hardware mess.  I have written class wrappers around different CAN hardware, and then made a single API for doing things that use most of these hardware types. But I haven't got permission to share it, and specifically the XCP and A2L side of things, leverages NI's toolkits in ways that I can't share it openly in the state it currently is.  Sorry.  If I had more time, resources, and didn't develop it on company time things would be different. The large majority of the stuff on my blog was developed over a week at home during a staycation.

I would not count on purchasing a license, causing the passwords to be removed.  Sorry.  Additionally the NI toolkits are often just wrappers around a DLL or some binary. This means for it to work it must hook into NI specific function calls to NI specific hardware.  The ADCS toolkit works this way and that's why I had to rewrite it to allow using different hardware.  The ISO 15765, XCP, CCP, KWP2000, UDS, J1939, and other CAN protocols are really just software layers on top of some frame level API.  They can all be written in a way that is hardware agnostic.  But NI's toolkits are not written this way. NI wrote their ECU toolkit to work with NI hardware, and they want to keep it that way. The hardware helps sell software, and the software helps sell hardware.   They don't have an incentive to have it work with other hardware.  But honestly their hardware is quite good. I really like the NI USB 8502.

Yeah multiple targets is the main issue I've had over the years. I have a great reuse library that is written well to work on RT or Windows. But making a single PPL for both targets is impossible. And having the palettes, and builds, and projects pull from the right PPL, and pull the other dependent PPLs, is such a major pain that I abandoned it.

Several things can be done to optimize TDMS writing.  TDMS has to occasionally write header data to the file to keep track of the data being written.  Because of this you can add one TDMS file to the end of another and it will make a valid file.  You can't for instance append an Excel file (XLSX) to the end of another and get a valid file.

So you want to minimize the amount of times the header data needs to be written to disk.  The easiest way to do this is to write multiple samples at once, or writing multiple channels at once.  You want to avoid writing single samples.  So build up N samples for your N channels and write them once the buffer is full.  The buffer doesn't need to be your whole 12-18 hours.  You can start small with say 10 samples and see how it performs.

Use the File Dialog express VI on the File IO >> Advanced  palette.  You can configure this to prompt the user for a file path then wire that into the open.

2 hours ago, Jordan Kuehn said:

Not to derail the above conversation, but can this ping function reliably time out in Windows sub 1s?

I went to dig up my fast ping utility for Windows, but I see you were already in that thread.

As for this thread.  I rarely use the parallel for loop but when I do it is a more simple set of code.  It has those caveats Shaun mentioned and I typically use it is very small cases, and where the number of iterations typically are small.  In the past I did use it for accessing N serial ports in parallel to talk to N different devices sending the same series of commands and waiting for all of them to give the responses.  And I have used it for cases when I want to spin up N of the same actor.  Here there is other communications protocols to handle talking between processes.  And again these are usually limited to some hardware resource like two DMMs that are independent.  If it needs to be very scalable, and have large numbers of instances a parallel for loop probably isn't what you want.