-
Posts
4,883 -
Joined
-
Days Won
297
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by ShaunR
-
You'll end up writing a shed-load of code that realises your own bespoke pseudo database/file format that's not quite as good and fighting memory constraints everywhere Much easier just to do this:
- 13 replies
-
- 1
-
- large data
- text file
-
(and 2 more)
Tagged with:
-
The easiest (and most memory efficient) solution is to pre-process the file and put the data in a database and then use queries to decimate. Take a look at the "SQLite_Data Logging Example.vi" contained in the SQLite API for LabVIEW. It does exactly what you describe but with real-time acquisition..
- 13 replies
-
- large data
- text file
-
(and 2 more)
Tagged with:
-
Done. Agreed.. All LV arrays are "square" arrays, however this is inefficient for large data-sets. We could actually handle non-square arrays by using arrays of DVRs internally (again, the premise being that we would only convert to "square" when necessary on extraction).......just a thought!
-
Formula nodes: code readability comes at a price
ShaunR replied to Oakromulo's topic in LabVIEW General
Move the indicators out of the for loops.- 36 replies
-
- 1
-
Well. Decoding an N dim array is not that hard (a 1d array of values with offsets). But I'm not sure how you envisage representing it internally .
-
N dim arrays don't have a "type" but they are represented e.g. Array:[[1,2,3,4,5],[1,2,3,4,5]] This causes us a problem in the way we convert to type from a variant (recursion works against us due to the fact that it is not a recursive function. it is iterative). If we were just dealing with strings, then it would be fairly straight forward. For example. Using the "Set From Variant" in a for loop works fine for 2D arrays. But for 3D arrays it will give incorrect results (try with the "Example Creation of JSON string.vi"-bug). One way forward is to detect the number of dims and have a different "Set JSON Array.vi" for each (max 4 dims?). But this is ugly (POOP to the rescue?).
-
I could argue many aspects of that. The windows API is a much stricter license however (Creative Commons Non-Commercial Share-Alike). More importantly. In the case of the code that's taken from the windows API, an attempt has obviously been made to pass it off as original work (plagiarism in academic circles) otherwise, why change the icons, the distribution format, remove the attribution notices in the revision info and license file. That's just "not cricket" and should annoy you in terms of your code as much as it does me. I'm not saying that the person that posted it on NI.com did this (although they have opened themselves to the issue). They could have innocently picked it up from somewhere else. It does however highlight the importance of licensing and the validation. if not commercial gain, that some seek from the efforts of others. Maybe a MOD can move these comments to the licensing thread so as not to gum up this support thread?
-
Well. in my defence. They were originally written in about 1997 before all the new fangled icon bitmap editing. When a customer complains about icons rather than bugs; maybe then I'll change them
-
Indeed. He has been a busy ;little squirrel. This drives info is taken from my windows API (windows_api_Drives.llb).
-
I ran the updater on that machine (had to drag it over to the offices to get an internet connection), updated everything and the problem seems to have gone away. It solved the problem, but I can't tell you which patch/update/package was the one that fixed it and I can't now replicate the problem-just needed to get it working.
-
Yup. I think lvanlys.dll is installed with the Device Drivers CD (the machine also has 2012, but the lvanlys.dll seems to be from 2010). That would also explain why it affects all versions. Just downloading the latest Device Drivers installer to see if that cures it.
-
I've been troubleshooting some code to find out why I was getting corruption in waveforms when using the Pt-by-Pt VIs. It seems that it it a problem with the latest lvanlys.dll in the run-time since older installations do not exhibit the problem. It affects all labview versions (from 2009 onwards) and both 32 bit and 64 bit. This is the result from an installation using lvanlys.dll version 9.1.0.428 And here from an installation using lvanlys.dll version 10.0.1.428 The problem is that the output is switching sign at arbitrary intervals as can be seen in the following table:
-
Formula nodes: code readability comes at a price
ShaunR replied to Oakromulo's topic in LabVIEW General
Formula nodes are for c and matlab programmers that can't get their head around LabVIEW (or don't want to learn it). It's well known that it is a lot slower than native LV and it's a bit like the "Sequence Frame" in that it is generally avoided. I would guess there are optimisations that LabVIEW is unable to do if using the formula node which are reliant on the G language semantics (in-placeness?).- 36 replies
-
Inheritance in this situation feels a bit icky...
ShaunR replied to GregFreeman's topic in Object-Oriented Programming
You could always do it the easy way and just extract the bytes to determine type and link them to a case structure for decoding. -
Change the Background (Rotate Func.)
ShaunR replied to Biker777's topic in Application Design & Architecture
Nope. Nothing wrong. The ""unflatten pixmap" strips the alpha-channel and coerces to 24 bit. I suggest you use the rather excellent "BitMan" package in the CR. -
Which class should hold this data...
ShaunR replied to GregFreeman's topic in Object-Oriented Programming
Actually it is quite possible. Use Events and all zones register and filter for messages. This is directly analogous to what the CAN bus is doing. -
Do you aim to get users working quickest or do you aim to teach?
ShaunR replied to Mr Mike's topic in LAVA Lounge
That's what training courses and seminars are for. Forums (to me) are for the "I've got this problem with this code,, anyone know how to fix it?" questions and general, unstructured "discussions". Therefore I don't see them as an ideal or even particularly good platform for "training". Most people IMHO post and want/need an answer in a day or so. Understanding architectures takes longer than that and doesn't solve their immediate problem. So using your analogy. They already have the bloody stump. I usually give them a band-aid and tell them how not to lose the other one -
You also need to know the type ahead of time with the others as well (supply a control to define the type). I would prefer it just coerces to the type of the indicator that I hang off of it which in fact is more useful than the "To Data" and James would get his function without having to define the type input. It (i think) should behave like a polymorphic VI but we don't have to write all the cases. Until that happens. I'm still using strings and variants (to me) are still the feature that never was.. Can I also reiterate my long standing peeve about not being able to create "native" polymorphic controls/indicators. X controls is another "half" solution.
-
Do you aim to get users working quickest or do you aim to teach?
ShaunR replied to Mr Mike's topic in LAVA Lounge
Users posting on a forum tend to have been trying for a while to get round a specific problem or lack of understanding. Muddying the waters with architecture (when not asked for) tends to just confuse and frustrate. I'm reminded of what a teacher once said to me for exam technique. Answer the the question, not what you think they are asking. I tend to solve the immediate problem (usually with an example) then suggest improvements. However. Rolf has a huge amount of experience in umpteen programming languages as well as solving comms problems on a day-to-day basis so his one-liner is second nature. It helps when they post an example as then you can tell their level of expertise. If they have roughly hacked an example shipped with LabVIEW and it "sort of works". They may have spent all day trying to get the last bit sorted. This generally means that they if you start spouting about OOP and Actor frameworks, then they will probably just give up as "LabVIEW is too hard to do simple things". -
Network Messaging and the root loop deadlock
ShaunR replied to John Lokanis's topic in Application Design & Architecture
Depends how many dispatchers you have. If you have a single dispatcher (centralised server like a DNS server) then yes. If you have a dispatcher on every machine (like apache), then no-as long as you have reduntant processes elsewhere. The usual topology I use is to have a machine with, say, 5 processes and replicate that for failover. If the machine goes down then you just point to the other machine(s). That's the way the web works But haven't we discussed this before? -
Network Messaging and the root loop deadlock
ShaunR replied to John Lokanis's topic in Application Design & Architecture
Yup. I meant the example to show dynamically launching of TCP processes (there are hidden "handlers" which are dynamically launched). I don't see any reason why it should be an issue. Launching dynamic VIs means you can run them in separate threads and/or execution systems from the launching process so although your dispatcher might be in the UI thread, the spawned processes need not be.