Jump to content

ShaunR

Members
  • Posts

    4,848
  • Joined

  • Days Won

    291

Posts posted by ShaunR

  1. 57 minutes ago, Rolf Kalbermatter said:

    That would be a management nightmare. There would be no possibility to handle more than one event registration to subscribe to the same even generator without very involved buffer management. By placing the event queue into the event registration object it is fairly simple.

    1) Hey here is my event queue, post any event you get to it.

    2) I only have to check that queue to see if there is any event to handle. Not some other queue that might or not might have events present that I already processed but need to remain in it because not all event registrations have yet gotten to read that event.

    There is a relatively cheap check needed in the event generator to see if the event registration queue is still valid before trying to post a new event to it but that’s much easier than turning the single.queue into a pseudo random access buffer for use with multiple registrations.

    Similarly the event registration needs to check that the event generator is still valid when trying to deregister itself from it on its own destruction but that’s again a fairly simple Is Not an Object/Refnum check.

    I'm not really sure what we are arguing about here. I like events as they are (and have said so) and only said that I hope they don't change it the more general view of the LabVIEW API's. If you want me to seethe with indignation about implementations, then talk to me about reading an end of file as an error :D

  2. 14 hours ago, Rolf Kalbermatter said:

    That event queue is owned by the registration refnum

    It is indeed. But it doesn't have to be They could have decided it should behave like Queue's and an Event Reg merely creates a reference to the internal queue. IMO, Darren's nugget is a side effect of an implementation peculiarity (which you have explained in exquisite detail) rather than a philosophical design - a peculiarity I hope never changes :) .

  3. 57 minutes ago, Rolf Kalbermatter said:

    It's not a bug and there is nothing that could be fixed here.

    Oh I don't know. They could delete the registration queues of any registration that referenced the event that was destroyed - they have to delete the registration queue at some point, right?. Luckily, that hierarchy isn't implemented and hopefully it would be too tiresome to implement.

    57 minutes ago, Rolf Kalbermatter said:

    The event registration is special

    I love LabVIEW events. I rate them alongside Dataflow, sliced bread and putting men on the moon. :D

  4. I don't post on the dark-side but I thought Darren's Occasional Nugget 08/07/2023 was a nugget well worth commenting on over here.

    I have used this behaviour for a very, very long time. Every time I use it, I always have to convince myself that NI will not "fix the bug" like they did with events and tunnels. I always thought it was an anomaly when compared to the other  API's-but a very welcome one which, as Darren rightly says, "this behavior makes event programming more straightforward than other APIs".

    Darren's example may seem a bit contrived and convoluted so I would like to add a real-world, concrete, practical example which would not work correctly without this behaviour.

    image.png.f97d25c115c28ec9a67b9370f0a7e81e.png

    The example (which is one of many that use this behaviour) relies on the "On Status" event being fired after the the event reference is destroyed in the "Close" function. Actually it is fired twice. Once for "Closing" and once for "Closed".

    image.png.744b98c849e323d4d779eb63892e851b.png

    If the event on the structure's queue was not retained and actioned after destruction, then the "Closing" and "Closed" events may never reach the loop - it may not terminate. There would be a high probability that a "Closed" status may not be received and it would be a race between the event structure executing and the "Close". A specific "shutdown" event would have to be added and managed - greatly increasing the diagram complexity. (this one reason why "Tunnels" and "Actor Framework" are so complex).

    But it gets better. Regardless of the Destroy primitives, all data and status' from the "Get" function, in the executed order, are also maintained independent of the speed of execution of the event structure. This means that when in debugging mode we can see all the events' data and execution even after the Destroy function has been executed in the "Close". As Darren has pointed out, a queue reference would not behave in this way and report "Refnum No Longer Valid" making debugging a much more difficult task.

     

    • Like 1
  5. 51 minutes ago, JKSH said:

    Congrats!

    Fancy giving CBOR a go, if you're looking for something to do? It's designed to work well with CoAP. I'd imagine that the API can be modelled closely after Dr Powell's JSONtext.

    CBOR isn't a protocol so wouldn't fit with ECL. While there are a couple of encoding schemes like Base58 and Base64, they are one-shot enc/dec functions and not really an API.

    I think you already know what I'm going to say next. The request would fit better Dr Powell's JSONtext (as you suggest) since it' already has the API and just needs to swap out the parser.

  6. 14 hours ago, Bryan said:

    Is the 1606 1015 24 the hex values that would be shown in a string control/indicator when displayed in "Hex Display" mode (in "\ Codes" display it would be "\16\06\10\15$")?  If so, see below:

    image.png.b85b0534ebd22bb2713be8f80c538c7a.png

     

    You need to preserve the width (2chars per byte) otherwise your concatenated is incorrect (you have 4 1/2 bytes represented instead of 5 because of the 0x06 - see also the guy that wanted to insert 0's). This is a common "bug" that occurs in drivers.

  7. 16 hours ago, betnow21 said:

    make it a simple communicator

    Simple, huh? :D 

    16 hours ago, betnow21 said:

    am most concerned about error 91 (Error 91 occurred at Variant To Data in CLIENT.vi)

    That is a symptom, not the problem. You get that error because if there is a read error (your server shuts down the connection, read timeout or whatever), you still enqueue a message even when there is no data (and you have zero error handling).

    Wire the error terminal on the "Producer" to the enqueue and it will reveal the real error (probably 66). This will ensure when there is an error, no data is enqueued to the upper loop which should be named the consumer-you have them switched. The TCP read Produces the data and your upper loop Consumes the data.

    image.png.af8242258dc4e1a36c6e24c26bbb4228.png

     

  8. Your CLFN's are running in the root loop (that's why they are orange).

    You really need them to be set to "Run in any thread" but for that, your DLL has to be thread-safe. If it is thread-safe then change it. If not, you are stuck with what you have.

    • Like 1
  9. 12 hours ago, Lucky--Luka said:

    To get the exact value I should add 0 in the middle of the values when missing

    I don't think so.

    12 hours ago, Lucky--Luka said:

    4-byte hexadecimal values

    12 hours ago, Lucky--Luka said:

    2 8 D5 0 0 0 0 B 5 70 <CR><LF> (value: 46448)

    this should be (byte) grouped as

    28 D5 00 00 B5 70

    that's 6 bytes. I expect the last 4 bytes are the value so the first two (28 D5) are some sort of header. 00 00 B5 70 = 46448 so that seems reasonable.

    So. doing the same for your arbitrary insert...

    12 hours ago, Lucky--Luka said:

    2 8 D5 0 0 0 0 B 05 70

    28 D5 00 00 (but what about the B?) 05 70.

    since 722288 = 00 0B 05 70 we have [with our arbitrary insert]

    28 D5 00 00 0B 05 70.

    But that means we how have 7 bytes and have a 3 byte header instead of 2.

    Adding a 0 arbitrarily is not the solution here. You need to look at how you (the human) are understanding the data from the Arduino again.

  10. 1 hour ago, dadreamer said:

    I tried to be a little ironic, but failed, it seems.

    The problem is that what you described is too plausible - solve the symptom rather than the problem and automate the rigmarole work-arounds we normally go through instead of giving us the language construct that is needed. Look what they (not NI) did with C++ and templates :rolleyes:

  11. 33 minutes ago, LogMAN said:

    Perhaps diagram zoom could be utilized or the change could be displayed in an overlay (or both combined)?

    For example, there could be an icon to indicate that Nigel has a suggestion:

    image.png.1d2057737fd86abdafef356f453f9825.png

    When hovering the icon, it could display the suggested diagram in an overlay from which I can choose to apply them:

    image.png.cb2911d04cdc535047aa1573a3571516.png

    Suggestions could also be displayed on subdiagram level, depending on the scope of the suggestion. For example, 

    image.png.6992c8e9076b8162d9c2b4508f05c534.png

    Once applied, the diagram grows to fit the new content.

    Great idea. I'd prefer the second one with a slight modification - It has the icon (the bulb in your example) but you double click on it to view the suggestion. The suggestions are only displayed if a button in the toolbar is depressed (like the "Retain wire Value"). Oh. And a cancel/close button in the window.

    • Like 1
  12. 18 hours ago, dadreamer said:

    It should also automagically install Visual Studio, write the callback wrapper, compile it into a DLL and connect it to the VI with a CLFN. :) 

    I respectfully disagree.

    We should be able to use callbacks for DLL's just like the .NET callback node. However, that isn't an AI solved problem which is why I was laughing.

  13. On 5/27/2023 at 9:55 PM, mhenz said:

    Shame on you 🙂

    I did it and I'm still active, even not on the frequencies, but making videos, mounting antennas for the contest, painting the truck, climbing on the mobile tower ...

    here it goes... 

     

    I expect you could hear Marconi's original transmission with that set-up :D

    • Haha 1
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.