JamesMc86
-
Posts
289 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by JamesMc86
-
Its going to depend on how fast it needs to run but some general advice: Typically we don't use floating point numbers on FPGA as it takes way too much space. You will need to convert to fixed point maths. We avoid arrays for the same reason which makes this design tricky. You could use a FIFO to track the historical values though. Every time you add a sample you update the running total instead of re-summing all values each time, it would be much quicker and avoid the use of arrays. I would have a search for a moving average, I imagine someone has done this before. There is a mean in the FPGA palettes but I don't think it does a moving average like this, it will just output a value every time it has enough samples to calculate one
-
Yes! Just Yes! Would love to do this with VIPM in LabVIEW
-
Really excited to have an ongoing involvement in this project with National Grid https://t.co/31HhEg3gtd Read more at http://t.co/QBaZvNytl6
-
The reason the spec sheet reads strangely is partly due to this being primarily aimed at AC applications. The overcurrent protection is for 10Arms which gives you the peak value for 14.051A peak. This is rated for 1 second but remember that is at AC so the rating for the 14A instantenous is probably much shorter. Will it survive? possibly, but I think it is certainly out of specification for the card and will reduce the life. These cards basically work by having a small shunt resistor feeding a very low range voltage measurement. That 12mOhm resistor is the part that has to take the brunt of the current and will likely fail. If you need the fast response then you can use an external shunt resistor which you know can take the load and the NI 9238 which has a 500mV input range. The easier option is an external transducer as mentioned above but be aware of dynamic characteristics and precision with these as they are often worse than a shunt based measurement although have the advantage of affecting the system less.
-
Love Microsoft support: "Can you send us your license agreement?" Haha yes but it may read something like "You may have all the software"
-
The more I see about LabVIEW Linux RT, the happier it makes me, you can detect reboot cause: https://t.co/zykydosJv5
-
RT @qikipedia: Never trust a man who, when left alone in a room with a tea cosy, doesn't try it on. – BILLY CONNOLLY
-
Yes! How have I missed this "@chrylarson: Add websockets to your #LabVIEW project! https://t.co/nruIxxyl5q"
-
RT @Fabiola31416: Have you done any mock objects in #LabVIEW? Join the conversation at the Unit Testing Group https://t.co/p95UYv81xa
-
RT @chrylarson: Coffee or Spiders? How should I start my day? http://t.co/75eWiA6MRd #YourTurnChallenge http://t.co/MJHCR1yoyg
-
Every time I use TDMS, I think this might be easier with csv. Every time I use csv I live to regret it!
-
RT @Kurz_Gesagt: Dear science. Please hurry. I'm not expecting immortality but an extra century or two would be pretty nice. http://t.co/FS…
-
Appears to be fixed in 2014 RT @janesmc86 @labview mini-tip, always add scales to a graph AFTER setting font size :-( #wontgetthattimeback
-
I agree if we are just talking about a single VI but if we are talking about coupling APIs then dependency inversion (not "injection", stupidly similarly named but unrelated principles) useful pattern to avoid crazy dependency loads. All it really is is a form of abstraction layer. My understanding in LabVIEW is all it is saying is your messaging API has a child class which implements the TCP, then as you are noting, don't put this in the same libraries as this means then that the TCP messaging child is dependent on messaging, but messaging isn't dependent on the TCP child. For cases like this having additional libraries wrapping these together just reintroduces the unnecessary linking of the and breaks these principles. I quite like smithd's rule of thumb, (wildly paraphrasing!) if you wouldn't give them all the same icon, I wouldn't put them in a library together.
-
I used to use them for grouping seemingly related libraries but long given up for reasons described. It just creates an additional hard link and in many cases if already using classes doesn't add huge amount of benefits. I would second smithd's comments regarding the problem with links between classes. I would have an interface class (or even a cluster depending on whether data manipulation is required). Obviously the important thing is that it shouldn't depend directly on either class but they both depend on it, meaning either class can load without the other. What you start to get towards here is dependency inversion to decouple elements of code, there was a talk at the CLA summits last year that was recorded that I found to be a good explanation of this. Believe it was the US summit and the talk was by Dmitry Sagatelyan (number 15 in Mark Ballas videos).
-
The argument I have seen for not escaping them is because escaping increases the size of the data, in this case necessarily. From my point of view either could work, it just meant I had to change my code and do it properly instead of cheating!
-
Hi, Thanks for the update. The escaping problem turns out to be mine! I've been trying to compare output with that of the JSON library in Node.js. It actually only escapes the bare minimum which does not include / despite there being an escape character, so both are valid JSON, just not comparable.
-
Good architectures make development so much more enjoyable, expandable in all the right places, simple in the others. http://t.co/UMUtjmbvfp
-
RT @gregory_payne: It's always nice to be at the top of a #LabVIEW web search result. http://t.co/PeHK71ivPR @labvolution http://t.co/sm39o…
-
RT @AshishNaik: @nationalgriduk sharing their innovating work with @19jmc onstage in the afternoon keynote #NIDays http://t.co/i8tN26VjPe