Jump to content

ShaunR

Members
  • Posts

    4,897
  • Joined

  • Days Won

    297

Posts posted by ShaunR

  1. 17 hours ago, Neon_Light said:

    Hey ShaunR, most of it did work, the only thing the install complained about was:

    "Install National Instruments Device Drivers Now?"

    Are these also on one of the files you linked to? Or do I need to download them seperately?

    Device drivers are on a separate installation DVD (it'll be 10's of GB). While they are probably on the FTP site somewhere, you can download it from the main NI website.

  2. A long, long time ago in a galaxy not so far away I developed two xControls in order to create a VI installer. The VI Installer hasn't really gone anywhere but the xControls that it used were for a Toolbar and a Tab Control. (The string indicator which supports colours on the tab page below was another but that is already available - Markup String).

    installer.png.5d38bf443dd156ba3ea1c277d0e22ded.png

    The two xControls are pretty well defined and feature complete but for them to be introduced into the wild, they need "productionising" (documenting and tidying up FP/diagrams and creating VIPM installers). I've sat on them for years so it's not going to be me that does the last few percent and I don't want to be the one that people go to for support (I have enough out there already that I have to support). So if someone wants to take up the mantle, give me a shout and I'll figure out how to release them.

    The XControls are self contained with their own examples:

    The "Execution Toolbar" xControl example.

    image.png.50675ed53538e37b58ab3290db357b8f.png

    image.png.b62ccbd85006e551dfee28da8f7b2586.png

    The Tab Control xControl example:

    image.png.0c33ba088df0bae2542c5870025f1706.png

    image.png.0febb59758e897bd3c8662b904dd73d5.png

    If no-one is interested then I'll keep them in my private box and sit on them for another decade. :D

  3. On 11/3/2023 at 8:49 PM, smarlow said:

    so that the GUI can be used with other programming languages in addition to G

     

    On 11/1/2023 at 9:41 AM, ShaunR said:

    What we don't need is imports from other languages making it just as bad as all the others.

    Not a huge leap but an improvement on events (IMO) would be Named events (ala named queues). Events that can be named but (perhaps more importantly) can work across applications in a similar way that Windows messages can be hooked from an application-all driven from the Event structure. I initially experimented with a similar technology when VIM's where first discovered (although it didn't work across applications). Unfortunately, they broke the downstream polymorphism and made it all very manual with the Type Specialization Structure - so I dropped it.

    Another is callbacks in the Event Structure. Similar to the Panel Close event, they would have an out that can be described. 

    But getting on to the LabVIEW GUI. That needs to go completely in its current form. It's inferior to all other WISIWIG languages because we cannot (reliably) create new controls or modify existing ones' behaviour. They gave us the 1/2 way house of XControls but that was awful, buggy and slow. What we need is to be able to describe controls in some form of mark-up so we can import to make native controls and indicators. Bonus points if we can start with an existing control and add or override functionality. All other WISIWIG languages allow the creation of controls/indicators. This would open up a whole new industry segment of control packs for LabVIEW like there is for the other languages and we wouldn't have to wait until NI decide to release a new widget set. At the very least allow us to leverage other GUI libraries (e.g. imgui or WXWidgets).

    • Like 2
  4. On 10/30/2023 at 4:08 PM, Thomas_VDB said:

    LabVIEW is in great need of big investments/rework. As much as I disliked NXG, it was started for a valid reason. Without such investments, we keep working everyday in a development environment, who's foundations are (almost) 40 years old.

    Well. C++ is just as old and C is 10 years older - so go figure! The whole software discipline hasn't really moved on in the last 60 years (check this out!) and while I do see AI changing that, it's probably not in the way you think. If AI is to be instrumental to programming it must come up with a new way of programming that obsoletes all current languages-not automate existing languages. Software needs it's Einstein vs Newton moment and I've seen no sign of that coming from the industry itself. Instead we get more and more recycled and tweaked ideas which I like to call Potemkin Programming or Potemkin languages.

    On 10/30/2023 at 4:08 PM, Thomas_VDB said:

    I don't see such a thing coming for LabVIEW, which will rapidly make LabVIEW fall behind in comparison to other languages.

    I disagree. LabVIEW, so far, has been immune to AI but it has also been trapped in the  Potemkin Programming paradigm (ooooh. PPP :D). It needs another "Events" breakpoint (when they introduced the event structure and changed how we program). Of all the languages, LabVIEW has the potential to break out of the quagmire that all the other languages have languished in. What we don't need is imports from other languages making it just as bad as all the others. We need innovators (like the guy that invented malleable VI's for funsies) only in their 20's and 30's - not 70's.

    • Like 2
  5. 13 hours ago, X___ said:

    No, it did not. It did mention that groupdocs was not free though!

    What puzzles me is that it did not mention that this was a standard feature of the python PIL package:

    from PIL import Image
    import matplotlib.pyplot as plt
    
    filename = '/content/drive/MyDrive/my image.png' # point to the image
    im = Image.open(filename)
    im.load()
    plt.imshow(im)
    plt.show()
    
    print(im.info)
    print('Metadata Field: ', im.info['Metadata Field'])

    which is probably the approach I will use in my migration to Python experiment.

    You've really been gulping down that AI coolade, huh? :D

    I was going to mention PIL but IIRC it only supports standard tags (like the .NET that you criticized) so didn't bother to mention it.

     

  6. Being picky :D

    52 minutes ago, ensegre said:

    in my case I don't see appreciable differences between x3 and compound +++

    vs

    20 minutes ago, ensegre said:

    ~117ms with compound +++, twice + x3 and 3x, whereas ~127ms with compound arithmetic 3x or x3

    Can't be both ;) (and that's 10ms)

    However. You have a timing issue in the way you benchmark in your last post. The middle gettickcount needs to be in it's own frame before the for loop.

  7. Quote

    Add new class as main test project class and change inheritance make TestLite/Core/Project.lvclass as parent of your project class.

    Nope. Not gonna fly, I'm afraid. This is the problem with LV POOP.

    I like the bit at the end-a video to show us just how complicated it is.

    Is this a Test Stand lite? Or is it actually a test framework for unit testing?

  8. What are you expecting? DC is in the extended character set.

    In the help for the To Lowercase function it states:

    Quote

    It also translates any other value in the extended ASCII character set that has a lowercase counterpart, such as uppercase alphabetic characters with accents

    What it converts to is probably dependent on the code page you are using. 

  9. Nicely written but doesn't work for me (LabVIEW 2023 64 bit on Windows 10) using this image:  dark-noise.png.1083886a707d7d656369953c52c6220d.png.

    It hangs and never returns in "Point to EXIF Data - PNG.vi".

    The while loop never terminates as "Get File Position.vi" returns Error 4 (end of file) and there is no check on errors inside the loop so it keeps going and incrementing "Offset past chunk". Additionally, there is no check on the value of the "Offset past chunk" in case it has increased beyond the number of bytes in the file (optional defensive programming).

     

    image.png.ac15e6c0b91193ec145fdfadfca48fd1.png

    You also have a custom installer which doesn't create all the palette icons correctly. I would recommend you look at the JKI VI Package Manager which is the defacto standard method for creating and installing addon packages.

  10. 22 hours ago, hooovahh said:

    My problem with this, is that for some tasks if I do it in LabVIEW it might take a week.  And if I were asked to do that task it in any other language I'd ask for a year. 

    Well. If I were your manager then I'd ask you to find a contractor that can do it in a week and task you with managing them. :P

    21 hours ago, codcoder said:

    The point I'm trying to convey here is that people often become closely associated with their roles in their respective fields, not necessarily as a programmer in the language that dominates in that field.

    I feel this is a different point.

    I am a Systems Engineer and a programming language is a tool I use to engineer a system :lol: That is different from what I was saying that languages are pretty much all the same. The latter is a poke at the industry lacking diversity in it's approach to programming and that I (and others) only see a difference in syntax and not really in execution. You might argue that Ladder Programming is a different beast to C/C++ (which it is) but both of those are 50 years old. LabVIEW has more in common with Ladder programming than any of the more modern languages which is why many people struggle when they move from a text based language.

    There are 32 types of hammers but they are all still hammers. That's how I see programming languages.

    • Like 1
  11. 1 hour ago, codcoder said:

    You're a front-end web developer first and a JavaScript coder second.

    Are you? What has front end web development to do with Node.js?

    Quote

    Node.js® is an open-source, cross-platform JavaScript runtime environment.

    I'm guessing you have only used Javascript for client-side browser scripting. Don't forget, client-side Javascript is nothing without HTML-itself another language.

  12. 1 hour ago, codcoder said:

    Just because you know JavaScript as a frontend web developer doesn't mean you can transition to C and become an embedded developer.

    I don't see why not :)Javascript syntax and structures are based on Java and C so it's a much easier transition than, say, to embedded Python. The point here is that it's not the language that makes transition difficult. It's the awareness of the limitations of the environment and how to access the hardware.

×
×
  • Create New...

Important Information

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