09-22-2015 03:01 AM
What is the R/IQ block called as? Sorry I am a beginner. Could you share the .vi
09-22-2015 03:18 AM
Dear johsold,
Can you post the .vi file . I am new to labview.
Regards,
kim!
09-22-2015 06:30 AM - edited 09-22-2015 06:55 AM
Quotient and Remainder
09-22-2015 06:50 AM
03-15-2018 04:57 PM
@RavensFan wrote:
Also Reshape Array, then use Index Array to get the row or column of interest.
This is smart!
I'd just use a Mathscript block:
output = input(1:interval:end);
very intuitive...
03-16-2018 12:55 AM - edited 03-16-2018 12:56 AM
@PetheGreat wrote:
This is smart!I'd just use a Mathscript block:
output = input(1:interval:end);
very intuitive...
03-16-2018 08:10 AM
@altenbach wrote:
@PetheGreat wrote:
This is smart!I'd just use a Mathscript block:
output = input(1:interval:end);
very intuitive...
- I would not recommend to do that.
- Don't self-identify your ideas as smart. Seems arrogant.
- It's not intuitive to a graphical programmer.
- Mathscript costs extra. Many don't have it.
- I am sure the performance of pure g code is much better and simpler
- ...
Well.
A. I wasn’t being ‘arrogant’ I was saying using reshaping the array into matrix and extract a certain row was a smart move;
B. I don’t know why anyone would read the paragraph that way with cofirmational bias...
C. I’ve never met anyone who started off programming with LabVIEW, so for most people graphic languages is definitely not intuitive.
D. I’ve talked to my programmer and we should admit each programming language has pros and cons. The flows in LabVIEW aid definitely more logical in some cases, the programming always ends up in a mass. And since LabVIEW does not support zooming in and out, locating different parts of the code is always a pain in a ass. However this many versions of LabVIEW have been promoted and there’s little change in user-friendliness and people are still complaining.
03-16-2018 10:48 AM
@PetheGreat wrote:
@altenbach , the programming always ends up in a mass. And since LabVIEW does not support zooming in and out, locating different parts of the code is always a pain in a ass. .
Sorry for misunderstanding parts of your post. It is good to be concise, but two-word sound bites are often not clear enough. Looking back, you apparently commented on the "reshape array" solution and I don't fully agree with your assessment because it creates an intermediary potentially gigantic data structure, just to throw most of it away a nanosecond later. Gerd's solutions is probably significantly more efficient. Reshape array does not always operate in-place, so we need to be careful. Sometimes, the LabVIEW compiler does wonders though, and only careful benchmarking will identify the best solution. FOR loops are extremely efficient and their absence is not a reliable factor.
Creating a mess is a function of the programmer and happens equally with text based code. I have written gigantic LabVIEW programs and they never turned into a mess at any point. The only difference is that with LabVIEW, spaghetti code might actually look like a plate of spaghetti and is thus easier to identify as such. 😄 ... and it actually might still compile and work! 😮
And yes zooming is fully implemented in LabVIEW NXG. Still, I never felt I needed zooming in classic LabVIEW, except when looking at code of others posted in the forum here. 😉 If you need to zoom out, your diagram is too big and wiring would be impossible in a zoomed out state. (Many wires are single-pixel wide and it is not easy to work with fractional pixels without side effects). We do have the navigation window. If you need to zoom in, maybe your monitor is too small for its size, but windows has accessibility features that allows zooming as a workaround.