All Activity
- Past hour
-
hotaru805886 joined the community
- Today
-
luoxl joined the community
-
BYU joined the community
- Yesterday
-
@Mahbod Morshedi no need to apologise at all. This is a journey for everyone and all the opinions here are given with absolute kindness in mind, just sometimes the message gets lost in text. If you add new features to your application, there is no need to make a new wire. Assuming you have some kind of core cluster you would just have a single wire through the whole application and you can add new stuff into this cluster. Now, that will start to get clumsy at some point (when it reaches what we sometimes call "megacluster" status). To prevent this from happening it is normally better to try partition your application into independent things, (loops) that contain just the data they care about. Then each thing becomes simpler. Then you need to figure out how to communicate between these things and you go down a rabbit hole. Have you looked at one of the popular frameworks like DQMH?
-
aaha20 joined the community
-
Abrahamx2 joined the community
-
Mi9D joined the community
-
YYFW joined the community
-
Hi All, Thank you for all the help and helpful comments: 1 - You all were correct about redefining variant attributes. I realised that, and good god, it is easier to use. 2- For the polymorphic VIs, I appreciate the primitive data form of the polymorphic instance. However, I am a scientist in the lab, developing several software programs that facilitate the acquisition, display, processing, and exporting of data from various equipment and experiments. Since I am just learning all these tools and admittedly not a very good programmer, I occasionally make a tweak or add a new feature. Then I realise, 'Oh well, I need this extra data cluster for backup data, and it has to be labelled...' In cases like this, a new data wire is created, and it is too much of a hassle to go back and fix things, add a new terminal, or change VIs to deal with this new data type or to accommodate this new wire. That made me look into variants and consider a single wire to rule them all. However, to extract the data (Unique clusters or any other types), I thought it would be best not to have to modify any VIs. I imagine I make a polymorphic VI, so for any new thing I want to add, I have to copy the same VI and change the data type of the variant to 'data'. I hope that clarifies my intention. I agree that my lack of understanding of the correct procedures and jargon can cause a lot of headaches for you guys, and I apologise. Cheers, M
- Last week
-
Cesar Mompar joined the community
-
jdzxgsfd joined the community
-
arashed07 joined the community
-
I think you'll find the polymorphic VI is used to get the data back out again. One of the issues with LV is that it's very easy to get data into a generic form but it's a bugger getting it back out again due to strict typing. I used the polymorphic method for reconstitution when I created a JSON parser that encoded to string (the ultimate variant) and one chose a polymorphic instance as to how you wanted it back out (string, U64, DBL etc).
-
I have this .vi that uses a multiple tasks, and recordings are saved into separate files for each tasks. Each task is meant to be recorded with different acquisition rates. From data postprocessing I realized that each task data are not time-synced. Is there any quick solution to fix this issue with my .vi? RR_Trigs_1.vi
-
yup, completely agree with this ^^^^ I have done something similar in the past where I used a global variant as a data store, and then used attributes to store/get data (and some convenience VIs to convert to the known types). It was a bit of an experiment in a system that had many data generators (different interfaces to independent pieces of hardware) and several hundreds of data variables (tags) all communicated over OPC-UA, so had a fairly sophisticated method to set/get by name as I didn't want to deal with such a mega-cluster anywhere. It worked fine, but in the end I would not really recommend it for simple systems where you just dont want to make the proper data types.
-
You are reinventing variant attributes and the corresponding primitives (see my post above). This being said, there is a lot of things to be commented on your code from a G-style point of view :-) but I'll leave that to others. As far as wrapping the Variant to Data primitive into a polymorphic VI, see my comment above as well. A nicety, but is this really worth the hassle? I have done that myself for a few common types (numerics, string, path, and array of such) and I find that very handy, but I wouldn't bother for types I use occasionally, and in particular, application-specific types. Just my opinion.
-
Is it possible to use TestScript as a type of test sequencer in LabVIEW where the UI can display the 'script', which would be python code, and be able to run in single step mode or at least be able to highlight the current python line being executed.
-
I am fairly new to source control in general and am trying to get git integrated with LabVIEW and am using TortiseGIT on my machine. I saw the pinned post about "run this script and things will be set up for ya" regarding LV Compare/merge, but it didn't work for me, so I am manually adding in the file extensions to TortiseGIT and I ran into a bit of a snag that I wanted to get some input on. I have LV 32 and 64 bit installed on my PC and am unsure how to handle adding in LV Compare/Merge. I say this because, as far as I am aware, TortiseGIT can only run 1 program per file type. When talking with ChatGPT about it, ChatGPT recommended making a script that checks the file's "bitness" then running the correct version of LV Compare/Merge and use that script as the "program". To me, it makes sense, but I also do not know what I do not know. I wanted to see if other people have run into this issue and what their solutions were. If it's a "google it" thing, can I get some direction regarding what I should be searching for? I don't mind putting in the legwork to learn, but I also don't know where to start with this issue and I've been flailing around in the dark for a bit and it's getting super frustrating. Thanks.
-
ensegre started following Find all instances... of FIFOs
-
So I have been given this monster FPGA project to patch. The main target VI is a monster with a BD of 9034x10913px, with 72 different loops . Yes there is some documentation an comments, but that does not really cut it. The logic uses I haven't counted how many tens or hundreds of different FIFOs and memory locations, read and written by this or that loop of the hyerarchy. Why, Why, don't I have a"Find all instances" for FIFOs , like there is for VIs, to navigate them?
-
Maybe the question is if you have to be committed to this array of clusters of string+variant for some specific reason, or if it is an attempt to implement some architecture which might have a different implementation. I.e., I don't understand if yours is a general question about design, or a specific question about the mechanics of converting variants to data.
-
Without getting into it too much , big picture , how limited would we be with PXIe and Base ?
-
X___ started following Using polymorphic VI as data selector for a Var_Tag array data type
-
Maybe the OP is trying to achieve a generic storage container (functional global of sort) using a variant. Something akin to this: Here I am using a typedef enum (Variable) to ask for a specific item, which is stored as an attribute of a single variant. There is no need to use a DVR to avoid copies of the variant (if that is the concern), as the only thing which is needed is a copy of the accessor VI (shown above) wherever a variable is needed. There is no need to bother with a polymorphic VI as the output variant is of the requested type and will easily convert to the right type of wire with the drop of Variant to Data primitive, as long as the resulting wire is connected to a terminal. If not (for instance it is connected to a numeric primitive), then yes a polymorphic wrapper VI might be neat (but still a lot of work). When adding a new attribute, simply modify the Variable typedef and add a case. No VI should break. The only drawback of this approach is that that VI has to be non-reentrant and therefore, wherever it is used, this will interfere with parallelism. This can be to some extent avoided with DVR read action, which might be the reason the OP chose that approach. My 2 cts.
-
Thank you, Neil and Enserge, I agree with you; however, while preparing my app, I realised that every time I needed to add a new function, I had to change data types or add a new cluster, which led to VIs breaking. This was the only solution I could think of to be compatible with every wire time in the terminals. Cheers
- Earlier
-
I have the table exported to Excel, but I've been encountering some difficulties. 01 - When I start a pump, the Excel recording starts, but if I stop and start the pump again in a few minutes, it ends up recording in the file itself, but it doesn't overwrite. 02. I need to start the pump OR press another button to start the report, and when I click stop recording, it doesn't turn off the pump, it just stops recording the report. I've been encountering these difficulties with my program; I need help. No mundo perfeito eu queria partir a bomba OU BT_IniciarRelatorio e pararRelatorio. E ao clicar em IniciarRelatorio OU PartirBomba, ele automaticamente criar um outro arquivo excel e alimentar com as variaveis.
-
I've tried all that and made a firewall rule exception to port 44525 with no change. After getting the error codes I restart NI MAX as admin and then it says Transferring Firmware Image but never finishes. Here is my question with more info on ni.com. https://forums.ni.com/t5/Real-Time-Measurement-and/Firmware-Update-Fail-on-cRIO-9045-Error-Code-80040390/td-p/4445281
-
How do you look up the data in your array? Via --Tag? If you are going to do that you might as well just use a map. But anyway, I am not a huge fan of this approach. I think better composition into clusters or objects will also make your wiring neater, more testable, scalable etc I do recognise the need for nice neat diagrams without wires going all over the place, but proper decomposition/architecture normally fixes this. So in general I would have to say you are not on the right track with this approach, but this is of course just my opinion.