Stinus Olsen

As an experiment, this would be pretty cool - but quite an undertaking I think. Personally though, I think I'll stick with using ComfyUI/A1111 and Kohya - they don't require me to install anything other than what I need for the task 😆 ComfyUIs nodes are a bit more versatile than you would think at first glance. I personally like to convert a lot of the frequent parameters I use into inputs and then minimize the remaining workflow nodes to not clutter up the interface. Inputs to the left, output to the right 😉 A fun fact is that if you save the generated images using the Image Save node instead of the Image Preview one, the workflow is stored alongside the image data stream inside the resulting PNG file. This allows you to load anyone of your previously generated images and immediately retrieve your workflow from that image - not much unlike how VI snippets in LabVIEW works :D

Well, in case you ever consider going that way, I'll recommend you start by looking at the LinkIdentity parts of the code Another vector for information could also be to look at the codestreams in the "Ned, the friendly debugger" interface. While I haven't peeked much at Flarn's later progress, I do know that NED will let you switch the format of some VI resources into XML (Heap Save Format) - dunno if Flarn is utilizing that?! (be warned though - this will most likely certainly cause LabVIEW to crash if trying to load the VI afterwards) Also, for quick low-level access to the Resource Fork of LabVIEW VI's and a lot of other NI resource files -from inside LabVIEW- I suggest using the REdLoadResFile/REdSaveResFile (interface)functions found in LabVIEW.exe. That at least cut away one level of abstraction for me, back when I had the time to immerse myself in this kind of 'research'. Now off to figure out the "Keep code streams for heap peek" option..

While I know this topic is a bit old now, I just wanted to point you to this thread that I created a while back. The behavior you're observing is a known bug in LabVIEW that currently doesn't have a solution - just workarounds that all relies on external components ?

Count me in on this as well! - I have quite a few ideas about where pipes would come in handy in my daily home- and work-related projects. I never really understood why this toolset hasn't gained more attention than it has, so I'll be happy to help testing and promoting it

From time to time I encounter one of these corrupt controls, usually when upgrading old code onto a newer LabVIEW version. This time I upgraded my main LabVIEW installation from 2013.0.1f2 to 2013.0.1f5, and somehow this single tree control ended up being corrupt - somehow.. I can set text color and style for the active cell, without an error from the property, but the tree itself doesn't update/change! I did some minor searching on NI and LAVA this.forum but turned up not-so-much wiser. Besides, the corruption (if that's what this is) can be worked around by replacing the control/indicator with another one, so nothing's really wasted except for the 2+ minutes it takes to realign the new instances appearance.. Is this a well known issue? I have attached a small (and fast) VI I copy pasted the 'corrupt' control into to visualize the anomaly. If the Tree reference is to another tree on the FP the code works as expected, and that tree is updated correctly.. Care to explain this? Tree Test.vi

Do you have a specific use for it to be able to read the VIs from within a built executable - or was it just a way of showing that the functions won't work with files in a executable image? Because thats a limitation of the NI function I guess I agree that the VI Server should be fixed, or the doc revised to correspond to the code - but if it's a matter of creating a 'temporary' workaound, it shouldn't prove that hard! I.e. you can access the VI files inside a LabVIEW executable image - but the non-NI way is not as easy as a simple property node (nor as pretty). Depending on whether the solution should run on RT/Linux, you could use the Windows API to unpack the main resource from the executable, then work from there, whereas if you were to do the check on RT or Linux you would have to manually unpack the contained resource. After that you would then parse the output (de-XOR'ed) archive, find and unpack the Resource Fork (VI File) in question, and finally use the REdLoadResFile approach from there.. As I said - not pretty or tidy, but definitely doable... Edit: fixed minor RT / Linux confusion..

Nope - the REdLoadResFile function is a public export from lvrt.dll as well. So you should be good to go with the RTE too.. (at least until NI some day decides to remove it for various reasons) Oh and by the way - here are the two missing functions to make the subVI folder complete.. (insert and save functions) Have fun.... Missing SubVIs.zip

Would this do the trick? Check for BD.zip

Here is a fix to the above mentioned problem. I have added an enclosing selector case as a guard against empty objects in the JSON Object::Unflatten function: JSON Object - Unflatten.zip (Backsaved to 2011) As I'm still not a BitBucket user, could one of you possibly add it to the repository? To test the code, create a file containing only an opening and a closing bracket "{}", and try to load it before and after the fix is applied..

According to most of the information I could find on the subject, the shortest possible JSON stream allowed is either an empty Object "{}" or an empty array "[]". However, when trying to parse a string containing only an empty Object "{}", I'm getting an error 1 in return - is this expected behaviour? I recon the JSON Object:Unflatten function should be able to handle at least an empty root object?

Here you go: Test and Bug Fix_2011.zip

Here is a small VI that shows the usage (and tests) the functionality: Test and Bug Fix.zip At the same time there is a small fix for one of the removal VIs that caused a null value to be created if the path to the value object to be deleted was non-existing..

Yes the fix works as it should! I use the JSON VIs as one of multiple backend providers for a general configuration module in my applications. For that purpose I've had to add a couple of additions to the toolset - and I don't see why those could not be a part of the standard functions, so here are a changeset: JSON Change Set.zip Maybe one of you guys could take 5 minutes to import them to the bitbucket repo?! (instructions are included ) The added functions are: - Setting (possibly overwriting) a hierarchy element, by index of an array of strings - Removing (deleting) an element, also by using an array of strings as index - Setting a value of path type by internally casting it to a string (my own way of circumventing the path-type-unsupported problem) And thanks a ton for some quick work yesterday on the TD fix

Bugger...now I remember what i forgot I dont have access to the code at the moment, but you can pretty easy set it up: Each of the 5 arrays should have 3 active elements.. Each element is a cluster of: - A string value: "StringValue" - An array of clusters containing only one element - A numeric value: "NumericValue" In the StringValue field, for the 3 indexes in each of the 5 arrays, just type some bogus value - Its really not important for the test.. The NumericValue field in the cluster arrays on the other hand are..! In the following you will only need to enter values in the only index that are visible (0) - the value you enter are not important, only if the array itself are empty or not.. Array 1: NumericValues are all empty... Array 2: Idx 1: Empty - Idx 2: Empty - Idx 3: some value Array 3: Empty - some value - empty Array 4: Empty - some value - some value Array 5: some value - Empty - some value Let me know if you got it, - if not I'll attach a new file tomorrow with the standard values set

I haven't had time to create a project, but I managed to whip up a small example showing off the unexpected behavior. JSON Test.zip I spend most of the day debugging this issue - and in the end I solved the problem by changing a value in my config data cluster from a type of U16 to U32, which solved the problem instantaneously.. Those were some pretty expensive 16 bits I managed to track down the reason as to why this happens, but still don't know if I know all the cases in which it can happen.. Edit: I haven't included any of the JSON VIs - so you're on your own doing all the relinking necessary to run the test..