ShaunR

This a blast from the past. SAE J1939 is an old Japanese protocol-the precursor to OBD. It has the same connector as OBD but slightly different pinout. If you look for software that supports early 90's Japanese car diagnostics, there used to be a few examples around. It's a bit hit-and-miss since, at the time, everyone was doing their own thing. If IIRC the early Mistsubishi's used it (FTO, GT, Galant) so a searching for J1939 with those names might reveal something. I very much doubt you'll find anything LabVIEWy so you will probably have to write a protocol driver.

Shameless plug but feedback would be great since there's a lot that's changed. A few more eyes on it would help immensely before going live. The Encryption Compendium for LabVIEW (ECL) has had a major update. It's completed and a couple of weeks away from release as the documentation is in progress so there may be a few errors on that front. It's a commercial package so the gibs free crowd will, I hope, be disappointed. So what's new? IPv6 support (Thanks Rolf for your help with that). I've been wanting this for sooooo long but it required moving away from the NI primitives and nasty text programming. I bit the bullet and now have it, although a lot less hair SFTP Since NI released their poultry offering I thought I'd productionise the SFTP I had in my back pocket for quite a while and offer something actually useful. It comes with a full client example and supports recursive uploads, downloads and deletions (be careful with that last one). It also uses events for progress and status feedback in a similar fashion to the Websockets below. The event topology will be come a common feature of protocols in future additions. Websockets The ECL is a better home than a separate product since it was very difficult to distribute when trying to support TLS. Reworked from the ground, up it sits nicely in ECL and is the start of more encrypted protocol support in the future. Oh yes. Almost forgot. The ability to use Windows Certificate Store because ... why not? (and I wish I had thought of it ) If anyone would like to play before its release proper in a couple of weeks time, I can give you a trial copy (valid for 30 days). PM me and I'll send you a link.

No idea (but highly unlikely). I've never used LabVIEW NXG and it's now defunct...so never will. Speaking of which. Does that mean we no longer have to call the proper LabVIEW "LabVIEW Classic"?

Not natively in LabVIEW. You have to use the IShellwindows interface in windows 10.

You didn't look very hard; did you! We've just been discussing the callback functions and posted examples of using them. The answer to your question though is no. you cannot use them in the way you are thinking.

In the Window menu on the LabVIEW toolbar there is an "All Windows" [last] choice (CTRL+SHIFT+W) that pops up a dialogue which you can sort. There is also a VI hierarchy and Class hierarchy graphical representation of VI's that are in memory that are accessible from the "View" menu in the toolbar. That may be easier for you if you are familiar with the hierarchies and the project is not too large (also highlights the importance of VI icons).

Nope. All the nodes are calls to the LabVIEW executable which houses the memory manager and you have most of what you need from the circular buffer example I linked to. Job done. I'll go to lunch.

One step at a time. Something about bridges and crossing them. After all. You have eloquently outlined the fall-back position.

Why have a work-around when you can have a solution?

You could implement it using the LabVIEW memory manager but it's not for the faint-at-heart. I once played with it for a circular buffer which isn't a million miles away from what you need. Oooh. Look. Words similar

Yes. That look familiar with windows forms. I've just been playing a bit more. I think there are messages posted to the thread from LabVIEW. PeekMessage will return messages targeted towards the thread (HWND = -1) and I thought I saw a 12 (WM_QUIT) from the LabVIEW Pid. Difficult to catch messages when you don't know what's being sent and Monte Carlo-ing in the debugger. I'll probably end up just logging them all to a file, but that will have to be next weekend. It'd be nice if it were just a case of peeking and then terminating on a WM_QUIT or our own ABORT

Yes. I understand and, as I said, I've used that in TCP. However. That's the user solving our problem and puts an onus on the user that I believe we can alleviate. There is a reason that NI specifically name a message pump for the UI thread. Basically I think that is only half a story.

Abort doesn't get actioned until the function returns since (as you rightly said) the callbacks run in the root loop. The function blocks the Abort callback until it returns. At that point, both abort and unreserve are actioned. So you cannot set an abort flag in your function when Abort is pressed. You can see this in the example if you set the nodes to UI thread and is why you need the message pump (I presume).

Only thing got from most of the companies I worked for was a pen set when I left.

I do this for TCP but what if I create a new HDC in the DLL node? Ala New(HDC), Draw(HDC), Close(HDC). The HDC must be accessed in the Root-loop so the Abort callback for New(HDC) would free it when Abort was pressed. Otherwise Close may never get called to free it.

Two reasons. Fully document the behaviour and operation as it allows us to do it.. Freeing resources that must be in the root loop (fonts or HDC's , for example). If you are referring to message pass-throughs where the message is allowed to continue on it's journey, it's what's required for form inspector tools so I've done that before (long time ago though). If that's what is required then it's fairly straight forward (famous last words ) The thing I'm not sure about is the hooking of the invisible LabVIEW window rather than the VI FP.

Here's a documented example with what I know (or think I know) so far. It may be a good starting point to fully flesh out the bahaviours without everyone reinventing the wheel. It's a work-in-progress as I learn more from this thread and discover the nuances. CLFN Callbacks.zip

Oh boy. This got complicated quickly Most modes of operation are per node (including UI) except run as clone which seems to be per thread. I'm not sure how that interacts with execution systems and execution systems across multiple VI's ATM. Running in the UI thread we obviously need "message pumping" for abort as per the dialogue that pops up. I presume this is referring to the the windows messaging to the form but may be wrong. I roughly know how to do this to normal windows forms and register user messages but without the main LabVIEW window refnum, I'm not sure how that would work. Anyone know what that looks like? Does anyone have a short example?

What's the scope of the InstanceDataPtr when run in User Thread? Does it behave like a LabVIEW-wide global pointer? VI-wide pointer (execution threads etc)? Or does LabVIEW still assign it a pointer local to the node?

Hmm. The returns from those functions seem to get eaten. Passing a mgErr back doesn't seem to do much. I would have thought they would appear at the error out of the CLFN. It'd be quite nice to report a "Canceled by user" error when Abort is called.

Indeed. It's all working great now. Thanks all for the help. When I get 5 mins I'll put together a working demo project and post it here.

Awesome. I was struggling with C malarky. Since it's hard for me to use extcode.h, I usually find the types and paste them in the header of whatever I'm using. However. I thought the InstanceDataPtr was a void * so I was using prototypes like this: Makes sense, right? WRONG! InstanceDataPtr is a typedef which means you can do things like *data = (InstanceDataPtr)malloc(sizeof(MyManagedStruct)); Can't do that with a untypedef'd void * so the compiler was bailing with: That caused me to try all sorts of pointer voodoo which would only work for a pointer-sized variable since: Looking at your replies it became obvious you were able to do something my compiler was complaining about and It was unlikely to be the compiler. This is why I do LabVIEW. lol

The CFLN has a page for callbacks. These are useful in certain rare cases but there is very little information available about how to use them, MgErr and InstanceDataPointer are defined in extcode.h and, it seems, InstanceDataPointer is a pointer passed by LabVIEW but there the information ends. Does LabVIEW free the InstanceDataPointer? - it is readable in the Abort, Reserve and Unreserve. Are we limited to a pointer sized variable? It's a (void *) so can we resize the memory it points to and, if so, does LabVIEW free that? (unlikely). Who owns that pointer? Does someone have a working, concrete, example (including C code) of the DLL side of these functions and how to dereference, write to and free the InstanceDataPointer? Does someone have skeleton templates for these functions that can make life easier for users like me, that know enough C to be dangerous?

I know this trick and it used to work but it seems to now be marked as a "toolkit" VI and it doesn't matter where you save it.

Well. I removed my offerings from Lavag about 4 years ago, so it works But the real reason i removed them was that there used to be a size limit and I ran out. I deleted all files so I could post images in the threads going forward. You'll also find a lot of my old posts that no longer have images.