ShaunR

Post your solution and we will take a look.

The NI-9219 has a programmable constant current source and +-25mA is the range, isn't it?. The examples show a default excitation current of 50 or 100uA. I don't know what the resolution is off hand so don't know if it can go down to 10uA, though.

I'm not sure if I'm understanding this correctly but you may be able to use memory mapped files. (I'm going to ignore the fact you are talking about TDMS because that may complicate things ) So you would create a mmap file twice as big as you need (right, I know. crystal ball time ). Then write file one from the beginning and file two from half way through. You can read out the data in any order, you like while it's being written by just addressing the bytes directly. So. For example. You could read line one from file one and line one from file two (half way through the map) and show those however you like. Alternatively you write each file into an mmap and read from multiple maps.

With these types of parms I usually pass in an array of bytes. ZCAN_CHANNEL_INIT_CONFIG.vi

Use the librarian file \vi.lib\Utility\libraryn.llb\Set VI Library File Info.vi. It has a boolean for Top Level.

DVRs are in 2009. I have thought twice about upgrading due to new features. Once was for the native JSON but it was so useless in the real world I stayed with my own. The second was the Start and Wait On Asynchronous call. My architectures could benefit from it but had no pressing need since I already have the tools to achieve the same result, Many people rave about self indexing tunnels. It was (is?) just some syntactic sugar for the old style so there were no performance benefits but It looked a bit nicer - hardly worth the risk of updating to a new version or keeping old and new versions of the code base. Some features (like the live moving of structures and wires) I detest but will suffer it if the needs must. Anything. that forces me to change my work-flow (like quick drop) I resist vehemently so you can add any of those to the list of why not upgrade. Be aware, though. I produce toolkits so the minimum version is important so that as many people can use it as possible. This is an incentive for me to go back as far as possible. It just happens that 2009 is pretty much bullet proof, no random busy cursors slowing me down and arguably still the fastest executing code. When it first came out I was so pleased that the pain and suffering of the buggy 8.x series was over and disappointed with most of the later versions for the same reasons.

It worked so it was was "correctly written" without knowledge of the underlying mechanisms and a method of how it "might" work in that way (like the DVR example) did not break dataflow. That aside. Was the bug fix reported in 2017 issues responsible for this change in behaviour? If so. What was the use case that it addressed where the behaviour was errant ?(an example would be nice)

He actually says they fixed it in the Kernel (~12:25) so they were off the hook because the downstream user wouldn't see it. I agree and I think I mentioned that earlier. But it looks to me like this was fixing an unrelated bug which had unforeseen consequences. It's probably a bug I've never seen in another fringe use case. I don't do this. It is something I vehemently practice as well as preach. One example was that I changed the compane of a VI in ECL.If the customer used the new examples it would be fine. If they used the old VI in their own software, the new one would be loaded and they would have to rewire. To make sure this didn't happen. I marked the old VI as deprecated and replaced it with the new one in the pallets. But I still ship the old one with the distribution so as not to break user space. It will remain in there forever. Another: The MDI toolkit was written in LV2009 (like everything ). Something broke the event refnums (like now, but much, much worse). To make it work in later versions, all the front panel event refnums have to be replaced. If back-saving; the same had to be done. There were 3 customers already using the 2009 version so I pulled the 2009 version and recompiled for 2013 (this is when it appeared on the LVTN). I now keep 2 code bases for the toolkit, Development is still done in 2009 and changes are forward-ported to 2013 - the new minimum version. I do not require the 3 customers to update their LabVIEW version to get bug fixes and features as that will break their code and there is no way for them to recover without also replacing all the event refnums. So you see. This is not the first time I've been bitten by events changing. Define "using" I develop in 2009 and recompile in later versions (see MDI toolkit above ). This is mainly because of TPLAT not supporting <2012? without putting special VIs in the code. Forgetting about 2009; 2013 is my next best/favourite choice (for stability and performance) but I have 2012 Linux and Mac versions for testing ECL so that is the minimum for that one. All the toolkits are tested in all versions on all platforms (except the MDI toolkit). From the minimum version to the latest, in both 32 and 64 bit.

Perhaps you should direct your comments to them instead. I also never said you misrepresented anything. I said you misinterpreted what I said. It's not a plea to authority. It is just a better oration of my own view with a preceding explanation as to the reasoning so that I don't have to write pages and pages. Your straw man argument doesn't help your case in this context. There is little point in continuing this branch of the conversation as it has just become me defending against unfounded accusations and that doesn't impart any useful information about the issue to anyone. If you have more technical input, then by all means please do.

I don't think it is a "read only on first call" and I never said as such. I intuited that it may be as described in the DVR example and was "a feedback node/shift register that was "initialised on first call". That was my observation of its behaviour and I wrote code around that. It obviously does work because your example taken from jacks stuff was written way before 2017 (2015, in fact) and before the change in behaviour and my examples show that it also works as expected when registering and re-registering in pre 2017 versions. I think you have just miss-interpreted what I said and then proceeded to jump up and down about the semantic meanings. I have been very clear, with examples, of what the issue is; what the change has been, and we have all discussed various work-arounds and alternatives. I may be a lone voice in thinking that it is unacceptable to change a behaviour that worked fine (as far as I could tell) for a decade but then I have to rewrite code, so it's understandable.

It relates to drjdpowells comment: Which I later went on to say: There was confusion between "refnums". I took it to mean the event "prototype" refnum (since that was my first example use case) and he was talking about contained renums. What I said was not "rubbish", though.

It can be done but it: because: Indeed it does.

and what happens if you change this "prototype" refnum? Maybe? Everything else is guessing but you should post some code to show your use case like everyone else has.

There is a bug fix listed for 2017 for the following. 596804—Re-registering a dynamic event can cause subscribing event frames to behave improperly There are no details beyond that but I suspect the behavioural change is a side effect of fixing this-whatever it was

Yup. My fault. I've changed the quote and noted in the edit. It also makes hooovahhs objection moot; for which he can carry no blame since I subtly misquoted. The sentiment is unchanged. It's well worth watching from ~8mins through to ~12. I agree 100% with him and it is the reason I pulled Linux support for my toolkits that aren't pure LabVIEW - even though they do work on that platform.

Ahh. You are talking about panel/control/user refnums contained within an event ref? Yes they are. That still works as expected <2017 - either before the structure or inside it. There was no bug here to prevent this use case. evnt5.vi

Is it distributed as a lvlibp?. There is a bug (quirk?) in the TPLAT for packed libs that shows an invalid licence for the lvlibp but it still works correctly as a binary distribution.

I'm not sure what "use cases" you are thinking of. But changing the event event reference null and voids all the cases using it. It is a design time, type, decision and can't be changed on the fly. The only thing one can do at run-time is listen for or stop listening for events. It seems, however, that if you really, really unlisten (Unregister For Events) then you are now stuffed.

Or they could have just left it alone ;)

It is representative of what it is doing now, maybe, and not nearly as useful. Also yes. If it had worked like that for a decade and I had written code to leverage it, I wouldn't expect it to stop working one day. Notice too, how a shift register, like the event, would restore the behaviour? Lets be clear here. It's not a difference between 2009 and 2017. It is 2017 differs from all versions back as far as [at least] 2009. I thought I had set the time start. anyhoo..... Start at about 8 mins through to about 12 mins.

Correct. The behaviour has changed. It used to work similarly as I described (and to the DVR analogy). Now it doesn't.

Well. Listen to this for a few minutes It is my sentiments entirely and I get just as annoyed and frustrated as he does with this sort of thing.. I supplied a prototype (DVR ref constant) to the the initialising terminal to fix the datatype and then initialise the DVR (with Create DVR). From my perspective. This is the same as supplying an event refnum to the left hand dynamic terminal and then initialising (registering) the event which is passed to the right hand terminal. In this analogy. The feedback node is hidden under the hood which is why the new registration miraculously appears at the left terminal after re-registering. I think it is just a better analogy than a queue which is also hidden.

I didn't say everyone. I said I was not the only one. You may be OK with breaking interfaces because of anal specmanship, but I am not. Behavioural changes have an enormous cost downstream. It wasn't confusing at all and, to be honest, elegant and compact. Not so much now. You chose a bad analogy with queues. Just because there happens to be one, doesn't necessarily mean events should behave like one. A better analogy from my perspective is DVRs. Would you consider this a "bug"? dvr.vi For the purpose of the analogy, the feedback node is hidden.

If that were true, then in your example you would also need to pass back the refnum to the right hand event terminal for it to magically appear on the left hand terminal (as Smithd showed) or use a shift register as I did. You also don't need to "pass-through" from the left terminal to the right like you would if it where a queue in a case statement.....and lets not forget "Named Queues". I appreciate your argument but events are a category on their own and your solution still breaks dataflow, by your definition, The fact that they may use queues internally is a hidden implementation detail and kind of irrelevant. It may explain why a decision was made to change the behaviour but doesn't mean it was the right decision. To quote Linus Torvalds I know for certain that I'm not the only one that relie[d/s] on this behaviour. I think I learnt it from Jack Dunnaway in his events presentation. Rule #1. You don't break user space.

The register is called later (and should create the queue later if that is internal behaviour). Your synopsis doesn't explain why a shift register works, either since that should also fail. It also doesn't explain why the unregister all events is unrecoverable. It also isn't documented in the 2017 bug fixes, if it is a "bug fix". You have just found a work-around to yield to the new behaviour. I argue that they have broken compatibility, introduced complexity and anomalous behaviour-they broke user space which is rare and unusual for NI.