ShaunR
-
Posts
4,849 -
Joined
-
Days Won
292
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by ShaunR
-
-
Can reproduce it too.
If you resize the window it sorts itself out. Looks like a refresh problem. I can get round it by writing to the bounds property of the vi (i.e forcing a refresh). But that doesn't enable you to "restore".
-
QUOTE (Neville D @ Apr 13 2009, 09:03 PM)
Does it matter if you lose a frame now and then?
I looked into using wireless camera's for checking rogue parts from from several bowl feeders that were feeding an assembly line. The process line was spread out over a 180sq ft factory floor with the operator in a cubicle at the end (wireless was an ideal solution). From testing, we randomly lost 1 in 30 frames on average and this went up to 1 in 12 if someone used bluetooth near the furthest feeder. Another example was a wireless remote alarm system that would feed back monitoring info to a central monitor. We had so many false alarms because the IT department had whitewashed the place with their wireless APs (it was cheaper than wiring and.....typically, they wouldn't let us near them!), just so the sales guys could wander around with their laptops and still have internet (although we did cause them grief as well
). I regularly VNC into machines wirelessly, but wouldn't trust it for serious remote control or acquisition.QUOTE (crelf @ Apr 13 2009, 09:21 PM)
Make sure there is arequirementto go wireless - some sites specifically rule-out wirelss (military, standards comissions, etc).Amen!
-
cFP are not cheap. You start at about £1,000 just for the controller and once you've added the backplane, and IO you are generally looking at about £2K+. RIO's (as far as I'm concerned) are just repackaged fieldpoints. Considering you will have multiple end points, you will need a controller for each point (NI will love you a lot).
DO NOT GO WIRELESS!!!! (especially if you are in an industrial environment) unless you really have to. There aren't many pro's but shedloads of cons.Wires don't drop connections and interference is rife in the 2.4GHZ band. Also solid structures (like walls, cabinets and even people) attenuate the signal immensely. Just search the net for problems people have getting a signal from one side of their house to another let alone 200m!.
-
Or you could just password protect them or save without diagrams.
The advantage of DLL's as proposed by djolivet is that they don't require the full development environment (do you really install a Full Labview License on every target machine????); just the run-time engine which is installed as part of test stand anyway! It really depends on how often you need to make changes. Generally, Vi's are always converted to DLL's as the last phase of the release before deployment especially if it is for a customer and not for internal use.
-
If you start with the Labview Test Sequence Example (which I think we would all agree is useless) and change the individual tests to a single dynamic load, add a report,pre-test and post test VI (again dynamic load). With a bit of thought about the Data interface (2D array works best
) you can pretty much do 80% of what Test Stand does with a text file that tells the program which VI's to load. Discuss....lol.
-
QUOTE (hfettig @ Apr 11 2009, 04:56 AM)
I am working on a project that will require a central controller with some analog inputs and digital IO but also two to four remote 8 to 20 channel AI devices. For the central controller we are considering cRIO or sbRIO. The remote DAQ devices could be up to 200m from the central controller. All they need to do is read voltages on demand. No high speed required. However, I have to be able to talk to in from LV RT.Unless you really need real time acquisition I wouldn't go with RIO (very expensive). PC as the controller (pc cards are cheap and you have the full flexibility and scalability of LV without the LV RT and memory restrictions) and any 3rd party ethernet acquisition modules (better channel count than NI e.g http://www.acromag.com' rel='nofollow' target="_blank">Acromag).
-
QUOTE (David Wisti @ Jan 23 2009, 06:04 PM)
I for one would purchase a license for scripting if it ever gets released as a product. Releasing it as an extra price adder for those that need/want scripting should keep the support cost for NI to a minimum compared to releasing for everyone.Yeah. Just what I need. Another license key to add to the 25 I already have!
-
Ive used Test Stand quite extensively over the years for testing and the biggest problem seems to be that it tries to be all things to all people. If it just stuck to being a sequencing engine then it would be fine.
If your tests are all read some data from a device, record the result and check for a pass/fail and and spit out a pass/fail report at the end and your doing that over and over again regardless of number of UUT's and no user interaction, then its superb.
However, if you are doing test like set a pressure and record the response over time and check that it reaches 70% in ...say 1 second, then you find it has severe limitations. In fact, you will probably end up writing a special piece of code to do that test because it's easier. If you have to write most of your tests in code, then basically you are just using it as a sequencing engine.
You seem to end up exchanging one programming environment (e.g Labview, Labwindows,c++ or whatever) for another (Test Stand). And Test Stand doesn't do it quite right! You also have to write a large majority of the tests in code anyway and make them fit in. I now use the rule of thumb that if I have to write special test code for 40% of the tests (like the example above) , then the Test Stand overhead isn't worth it and will opt for a proprietry solution.
As people have mentioned. It is a steep learning curve, but that is because you require an in depth knowledge of its features and functionality even to do fairly trivial things.
-
QUOTE (Ic3Knight @ Apr 11 2009, 09:11 AM)
Would that affect my writing to the device? If I send 0xC0 and that's the termination character, does it still get sent (my device is expecting a message framed with the byte 0xC0...)?Cheers
Paul
Using termination characters requires that a received message doesn't contain the character (otherwise you would return 1/2 way through a message). From your example, you only send 0x01's and 0x00's so jdunham is correct in that you can safely use 0xC0 as a term char for reading.
Sending is different in that when you initialise using the VISA Configure Serial port vi, it does not set the termination char for writing (take a look inside, you could change that if you wanted to), rather, it sends the string you wire to it and terminates immediately once sent regardless of the characters in the string.
So the short answer is yes 0xC0 would still get sent if you wired the term char 0xC0 to VISA Configure Serial port vi since the term char only affects reading.
-
QUOTE (crelf @ Apr 6 2009, 07:56 PM)
Like I said. It depends on distance and whether he wants to build an interface or buy off the shelf.
-
-
QUOTE (raymyster @ Apr 6 2009, 01:07 PM)
thank you mike for your reply i understand what you brought up...but the thing is we are not engineering students
& the doctor sugested somthing like this..i didnt ask for a 10 hour code of solution :S i simply asked for an idea like what shaunR suggested:
2 laser switches and the Parallel port VI example.
Move hand left, breaks beam 1.
Move hand right, breaks beam 2.
http://uk.rs-online.com/web/search/searchB...t&R=5103249
http://www.doc.ic.ac.uk/~ih/doc/par/
QUOTE (mross @ Apr 6 2009, 02:51 PM)
Yes, LabVIEW can do what you want. LabVIEW will do it much more easily than C++. But interfacing... I have not done that. I stick to LabVIEW.I do not see the point of lasers. You can use mechanical switches that cost a few pesos just as well.Thats not the brief.
QUOTE
we need to create 2 sensors with beams that will be projected to my hand, when i swing my hand left: a labview vi will detect that & send a left click instance to the c++ engine. & same thing vise versa when i swing right.QUOTE
With a proper data acquisition and control system, you can sense and respond to continuously changing inputs which will be better for aircraft control. A binary system - hand blocking laser versus hand not blocking laser - is an ineffective way to control all but the simplest systems. How will you tell it to turn slowly or quickly?Indeed but that is not the requirement. I imagine this is a learning exercise rather than a commercial product to fly airplanes.
QUOTE
Your parallel port is not easily useful. It is a digital system. You can use use this for sending simple digital IO, but this is a misuse - alot of trouble with little payback. If you have a microcontroller that can send parallel information (bits, bytes, and words) then it is used properly. Only in this way can you get continuous control of the aircraft.I Disagree. Little trouble and cheap. Bits, bytes and words are just highs and lows on a digital IO interpreted in a certain manner.
QUOTE
LabVIEW is a full featured software development environtment. The learning curve is steep, but significant. It does not seem practical to me that you should be using LabVIEW for this small project. You should be learning your C++ to do this.Apart from the fact that that Labview is more intuitive, has lots of examples you can modify for just this sort of thing and (more importantly) they have already done it in C++ but using a keyboard.
I think the most interesting conundrums will be when they want to interface the Labview to the rest of the existing system. There is no sane reason to use Labview for this trivial part of the project (and mixing languages is always more trouble than it's worth) when all they have to do is read the parallel port/digital IO or whatever interface they choose, directly from thier C++ program which is why I am lead to beleive this is a learning exercise.
function alert(m) {}
-
2 laser switches and the Parallel port VI example.
Move hand left, breaks beam 1.
Move hand right, breaks beam 2.
-
If you were previously using hyper-terminal then your messages are probably line feed terminated.
Make sure that the serial init is set to use a terminator and the term char is 0xA. Don't bother with the bytes at serial port property node and wire a huge number (say 1024) to the bytes to read of the Visa read.vi. The number has to be big enough to receive your longest message and don't worry......the read will automagically return on the term char if its less.
There is a serial example in Labview. "National Instruments\LabVIEW 8.2\examples\instr\smplserl.llb". Notice they don't use the bytes at serial port!
Getting LabVIEW Scripting out of the shadows
in VI Scripting
Posted
I do have a developer suite which on a SSP, and no. I don't get a single license for all the packages. Apprently thats only for a volume license agreement...I've tried!