David Boyd

I downloaded the code linked to by @huipeng8and looked at it a little over the past weekend, and I can tell you that I'm not especially impressed. It appears to be based off an older open source project (written in C) called libdmtx, started by Mike Laughton, but long since moved to GitHub and maintained there by others. I found that code to be harder to follow than the Zebra Crossing open source project (which I perused during my development; linked as reference code in my lvlib). Though likely I just didn't look at libdmtx long enough to grok it. My main grief with the LabVIEW code (written by NI user carroll-chan) is that it has absolutely zero BD comments, nor VI descriptions, so far as I've seen (s/ though it does have an endless variety of "interesting" VI Icons /s). And for any effort like this, implementing a very exacting ISO standard, IMO it needs to have some ties back to the standards doc. Also, please don't ask me how I feel about LLB packaging/distribution in the modern era.

It amazes me that I never found that bit of code, and it's right there on NI's site. I'll need to download it and have a look. Especially because I noticed that it claims support for all the encoding methods (ASCII, C40, X12, EDIFACT, etc), whereas I've left that for a future implementation - my 1.0 upload only supports ASCII. Just to be clear what that means - my library will encode any arbitrary string of 8-bit chars, it just means that there may be more optimal (meaning: shorter run length) alternatives. I did implement ISO 16022's rather arcane "look-ahead" test which tells you when to switch in/out of the other encodings for optimized length; I just don't have them implemented, so I don't make use of "look-ahead". Thanks, @huipeng8, for alerting me to this code, and for the good report on execution speed. Dave

Rolf, I must say that at least this ISO did have some example code written in C which I found helpful (and I quoted from on some block diagrams where the LabVIEW code might otherwise have been incomprehensible). I also included a link in my library documentation to the GitHub repository for the Zebra Crossing (zxing) Data Matrix encoder sources (Java). I will say that the LabVIEW is far from a "straight port" of either of those.

Brian, Darin's library implements QR, mine does Data Matrix; they're both popular 2-D barcode symbologies. QR seems to be ubiquitous (looks like most phone cameras now natively identify and decode it). Data Matrix (actually, the very specific GS1 implementation) is used throughout industry (especially med/pharm) to encode serialization/batch identification, use-by/expire-by dates, etc. I think every imaging scanner out there will read both QR and DM along with the endless variety of linear barcodes. I do believe DM encodes more data, at least it supports pretty large patterns with more capacity. When I came across Darin's QR library, it did inspire me to offer up a solution for Data Matrix. As I noted in my readme/release notes, I thought "how tough could it be?". After reading the ISO 16022 standard I think I nearly had a brain hemorrhage! Dave

Meh, I just used the stub to save some real estate on front panels (which are generally never going to be called directly by consumers of the library, so not really important). I'm aware that stubs have caveats, chiefly that they hold no actual default value, but that shouldn't be an impact here. Where used, they pass all the metrics of the pattern being generated (as a typedef). If it's bothersome/objectionable, the solution is simple - replace the stubs with instances of the control. But really, I was hoping the discussion would tend more to the "wow, cool..." or "when would you ever need to make these symbols..." or even "hey, there's already libraryX that does this...". I'm looking forward to hearing any discussion of the merits of having a pure-G implementation. Thanks all! Dave

View File Data Matrix Generator v1.0 LV2020 This project library enables conversion from string data to a 2-D integer array encoding Data Matrix ECC200 symbology. The library includes demo code to render the output to a LabVIEW picture indicator. Submitter David Boyd Submitted 05/07/2023 Category *Uncertified* License Type MIT  

Thanks, Dataflow_G! I really needed to see all those CRT monitors to be reminded of the passage of time...

The fullscreen point I get, sort of; coupled with a touchscreen, the corner "X" may not be the easiest to access. The target hardware will have a touchscreen monitor, although we'll undoubtedly leave them the mouse. And while they might fullscreen the main app window, by no means do they need to. For dialogs, I would generally offer a "cancel' button, and an "OK" (or "submit" or "proceed" whatever seemed appropriate labeling), and map keyboard enter and escape keys.

And I was errant in my description above, as you've both uncovered. On the original application, someone dropped the canonical rectangular pushbutton which comes with red "STOP" text; but they did actually change the text to "EXIT". My original point remains, though - what other desktop (non-LabVIEW) application features a button as the way to dismiss an application? For years I've just trapped window close attempts, and used those to start the decision process of whether it's proper/safe/etc, and handle the app exit gracefully (hardware known state, file/db management, etc). Dave

I've been working on a total ground-up rewrite of a production test application that was crafted in LabVIEW 7.1 in the early-mid 2000's. I got approval to do this since I really didn't want to glom the real required changes (mostly about hardware evolution) onto ageing software architecture, and (IMO) *way* overbusy UI. I'm talking multiple layers of tabs-within-tabs-within-tabs. I've worked to make a still-pretty-busy UI a lot flatter/simpler. I'm getting tweaked in validation reviews because I declined to include an explicit "stop" button to close down the application. (The application typically runs for multiple hours.) No matter how I try to explain that no other desktop application has a "stop" button (I just intelligently handle shutdown via the filtered window close attempt), I'm being told, "NO, it NEEDS a STOP button". Of course I'll give my manager what he wants, but I don't have to like it. OK, let's hear the sage advice and similar tales come rolling in... Dave

Reading twenty-plus-year old articles like that really starts to make me feel ancient. I was about to reply with the obligatory grumble about preferred-case spelling ("it's LabVIEW!"), and instead looked up the author. Found out he passed away just before MacWorld Expo 2007. Thanks for locating and posting this. Dave

I still have my "Power to Make It Simple" tee shirt that I "won" at the end of my three-day Basics I class (I think it was fall of '97... does that seem right?). The black is pretty faded. I was excited to upgrade from 4.1 and try out the miraculous "undo". And real multithreading (under NT 4.0)...

Thanks, @hooovahh, for pointing me to those older discussions, which I probably totally missed. @drjdpowell's comment about a clone's reference having guaranteed validity when passed to its subVIs doesn't seem to apply to my/@Neil Pate's use case - we're sending a cloneVI ref to another VI via messaging. So no telling when the original VI ref might go out of scope. And I just realized that my demo code for launching off clones (and then later gathering their refs for subpanel use), explicitly closes the original VI ref after they're launched. There is still a static ref on the caller's BD though - I think there has to be since you need a strictly typed ref to make the ACBR work at all. My demo code is below. Dave

I was browsing through class code from the Actor Framework (ashamed to say I haven't used this framework, yet, but that's changing), and stumbled across what appears to be a dire warning. (See the attached, or if you'd rather, read the BD comment here.) I've used an architecture for years now where I launch N clones of a VI using the ACBR in fire-and-forget mode, and subsequently the clones get a VIref to themselves and register that (with an assigned index) by message back to a GUI VI. The GUI then allows the user to switch through the clones' FPs to be shown in a subpanel. I've never had an issue traceable to this. Note that in my code, the clone refnums are NOT obtained by an Open VI ref with clone name string (as shown) - they are implicitly obtained within the clones via a VI class property node. Does this warning imply that this architecture is somehow unsafe? I'm hearing AQ's authorship in my head when I read this warning. @Aristos Queue, are you listening? Can you comment? (Apart from chastisement for my only now learning about the AF - sorry.) Dave