-
Posts
437 -
Joined
-
Days Won
29
Everything posted by X___
-
I am not sure I understand the problem: is this an IMAQ (DAQ) related problem or a Vision Development (image display control) issue? It sounds like the latter, but your inclusion of details of image acquisition is confusing. It might be totally irrelevant, but an app I develop in LV 2019 (using Vision Development 2019) failed to work when a user installed both runtimes on his computer (LV RTE and VDE RTE). It sounded like a Vision Development module license issue, which was strange as there should be a grace period for demos, but eventually it turned out that this was fixed when the user installed the 2020 runtime (I had selected the option to have the code able to be run with later version of the RTE). The symptoms were not a black image though (there was no image), but one of the VDE errors when one of the Vision VIs was called. My point is that there might be some issues with version conflicts... As far as trouble shooting, post your demo VI, I have 2018 SP1 installed on a machine where this is the only version isntalled, so I can test that.
-
I have been experiencing some weird "bug" lately, while using the Windows LV 2019 SP1 64 bit IDE, namely, the BD right-click context menu for objects only shows generic items (Create constant, etc.), completely failing to show the standard associated options (for instance bundle/unbundle for clusters, or New/Delete Data Value Reference for a DVR wire, etc.). I have found that tabbing through open Windows, or opening a new VI, in general is enough to restore the functionality, but this is very puzzling. Anyone else has experienced this type of weirdness? The only thing that I can think of that could be different from my previous configuration is that I switched to a new laptop (Windows 10 Pro), but I can hardly fathom why that would affect this installation...
-
I got confirmation that the attachments in my email were stripped off, and told that I could do exactly what Antoine just mentioned above. I am positive though that I was not offered this option when submitting the bug, which is a change compared to the past system. And again, there is no need for a S/N (a SSC number doesn't work).
-
It's getting better. First of all, gone are the annoying automatic acknowledgment emails. Not sure whether this is good or bad. After I received an email from a NI engineer asking me for details, I sent a demo VI and a test file (which I would have otherwise uploaded on the reporting site) attached to my email, only to receive the following after a few hours: So, either NI's email system strips any attachments from incoming emails, or the engineer doesn't understand English since I responded (and duly attached the two files): The last sentence is also worth its weight of peanuts... Obviously, I am reporting bugs because I get a kick out of annoying NI!
-
Try again. This doesn't work anymore. I received an email from NI, which I answered with an attachment, but this ability is gone on the website. Regarding S/N, you don't need one (this is specifically stated on the submission page).
-
Good catch. You'll love the expression node result!
-
Apparently, NI has changed there Support's website. - you cannot write a description of a problem. You choose your preferred communication means and write a one-liner topic, press "Send", and... wait to be contacted by NI. - you cannot provide example files when filing a bug "report". You can only provide "steps to reproduce". I guess there are so few bugs nowadays in LabVIEW that NI figured they could get rid of the whole obsolete process of filing detailed bug reports.
-
NI abandons future LabVIEW NXG development
X___ replied to Michael Aivaliotis's topic in Announcements
It appears that the Green Lady of NI has moved to even greener pastures: IBM - Biographies Can't abbreviate IBM (I?) but the website could use some of that pastel green and washed out pink palette NI has ambitiously engineered his website with. -
I am not sure there is any special functions in the MKL (at least I could not find any in the description) and all these are LV_something in the DLL call. There is really no wrapping to be done here, as the arguments are only a few. So maybe after all NI did code those (sometimes using lousy algorithms, as was the case for the Kummer function)...
-
Similar to the VI posted at the end of the blog post 3 above (with less granularity and the option to do the reverse by mistake! :-) In what sense is the project-level check box not working? I am interested because I have set the app-scoped flag to "remove compiled code" but still occasionally find some new VIs (created by "Create sub VI from selection") with their flag turned OFF. It is probably time for me to ask whether I am just victim of a LV virus or this is indeed a reportable bug (very irreproducible, so not very convincingly reported).
-
<OOT> In the case of the Kummer function (which I was referring to above), this appears to be an internal algorithm as the function is called LV_Kummer (there are a number of similar LV_functions in the lvanlys.dll). For the purely MKL ones, I guess we have to check the bug fixes here (without knowing which one is relevant for which LV version...): MKL Bug Fixes </OOT>
-
<DEBUG_OUTPUT> 3/12/2021 10:42:37.511 AM DWarn 0xFCC058F4: An item recompiled in the final iteration should not still have recompile needed set: [VI "ix.vim" (0x0000029f40dbd0f0)] e:\builds\penguin\labview\branches\2019\dev\source\compiler\compiler.cpp(621) : DWarn 0xFCC058F4: An item recompiled in the final iteration should not still have recompile needed set: [VI "ix.vim" (0x0000029f40dbd0f0)] $Id: //labview/branches/2019/dev/source/compiler/compiler.cpp#6 $ First comment: the penguin has reared its ugly head (or tail) again! I do not have a E: drive on my PC, so this is probably some internal stuff, as is the //labview/branches/... thing. The ix.vim is mine though and while not doing what I want, it looks pretty innocuous:
-
Kind of out of topic, but if confirmed, that transposes the source code source from NI to Intel... MKL forums seem to be indicating that obtaining source code from Intel is a complex and costly proposition. I wonder whether this is why it took 2 years to fix a numerical bug in LabVIEW (i.e. this was out of the hands of NI and had to be fixed by Intel): https://forums.ni.com/t5/LabVIEW/Bug-in-the-Kummer-Function/m-p/2387522
-
python What is the state-of-the-art of Python-LabVIEW integration?
X___ replied to drjdpowell's topic in Calling External Code
Project Dragon LabVIEW: Announcing Project Dragon - Managing LabVIEW Virtual Environments with VIPM - YouTube Project Dragon Sign Up - VIPM 2021 (jki.net) -
python What is the state-of-the-art of Python-LabVIEW integration?
X___ replied to drjdpowell's topic in Calling External Code
It was not free and indeed was carrying along a few MB of extra payload in each executable/distro. That link will not be usable by new users (as far as I understand) since they don't sell licenses anymore. -
python What is the state-of-the-art of Python-LabVIEW integration?
X___ replied to drjdpowell's topic in Calling External Code
What is the problem? As far as I remember I just had to tweak a path constant... However this is more than python. It's python in a Jupyter notebook (which is getting very popular in many circles) -
Sounds good. Will try.
-
I have my suspicions. But I like the terseness of the warnings (which pop-up only upon restarting LabVIEW). I suppose there is not more info that can be provided to the user (the LVInternalReports are binary files, so I can't make much of them).
-
The last time you ran LabVIEW, internal warning 0x occurred in image.cpp.
-
Appropriately enough, I recently got this startup warning as well: The last time you ran LabVIEW, internal warning 0x occurred in xstuffprivate.cpp.
-
Anyone has had to deal with this type of warning and know how to handle them? I have communicated the associated report several times but have now given up as I am sure NI does have better things to do (say bug fixes). LV 2019 SP1 64-bit on Windows 10.
-
From the foreword of Doom's book: "You owe me a shipped game every week, and if you don’t ship, you’ll get an F." Three classes and 127 games later, almost all of my students went on to jobs in the game 13 industry, no mean feat with a game design degree, and many of them credit the painful time constraints of the class. Terror works. I recommend it." I wonder how that applies to IDE development :-)?
-
NI abandons future LabVIEW NXG development
X___ replied to Michael Aivaliotis's topic in Announcements
I am reading through that lingo and am trying to extract the substance. What I read is that she was hired by NI for a specific job, did (or not) do it and was, if not fired, at least forced into a situation which led to her resignation after about a year on the job. That sounds rather short to me, but it is true that I am not privy to the way things are working on modern corporate boards. Maybe that is the new trend. I suspect there is more to it, and that her opinion that the business was run in a very outdated manner (saying that on a podcast sounds to me very non-politically correct) may have been the main reason. After all, her title is/was Chief MARKETING Officer, not Chief OPERATING Officer. Then there is the question of whether the "Good Ol' Boys" club might have reacted unkindly to a female outsider (I am not clear what her Dell and Rack Space background means in terms of her tech-savvyness. After all, she appears to have a BA in architecture and seems to only have held marketing positions).