Jump to content

ShaunR

Members
  • Posts

    4,897
  • Joined

  • Days Won

    297

Posts posted by ShaunR

  1. OK. I understand.

    I would be very tempted to just make your display a 2D array of strings (first column can be a label if you want). Then regardless of what data it is you can just format it in whatever manner you think is fit and append it. If it doesn't exist it will just appear as a blank (or you can insert N/A or whatever). If you hide the fact that it is an array, it will just look like a multi-line label. If you add more fields later, just make more elements visible. if you redefine fields , just change the labels (if you have any).

    The question I haven't asked properly is this. Is your problem just a method to display the info, or is it some intermediate stage that the data in your fields will be processed later?

  2. QUOTE (Val Brown @ Apr 17 2009, 04:44 PM)

    Shane et al: Yes that's what I thought but I guess the background implication in asking it that way is: Why isn't it internet enabled and/or why can't that be done just for this one operation?

    CRELF: Yes, I'm sure you're right because the only possible timeline I've heard discussed is that scripting will be released AFTER all the toolkits are implemented for Linus and Mac and the timeline for THAT to happen was something like "...when Bush gets elected for the third time." :P

    Because our IT is analy retentive.If I connect it to "THEIR" network then they have to have ownership which means the following:

    1. Cannot take the lid off to install cards. Have to send a support request to get the card installed which may be in 2-3 days time if I'm lucky. If found "tamperig with company property"....written warning :o

    2. No administrator priveleges. If software needs to be installed...Yup..you guessed it..Support ticket...2-3 days.

    3. Must have a defacto desktop/laptop PC with all the their crap and must use XP even if the customer wants Vista.

    4. The licence would have to be in one of their names (as you know...NI only supply support to the name on the license) so they can provide me with support <img> which means that yet again I would have to send a support ticket to get them to phone NI to asks a question which they know didly squat about.

    I will just point out though that I do have number 3 also. They decided that a dual core (not even core2) 1.6 GHz Toshba laptop with 512MB ram and a 20 Gig hard-drive is an adequate Labview development platform. It takes 20 minutes to boot in the morning if connected to the network because of their policies.

    Because of that, I run Labview, labwindows, test stand and all the toolkits on an industrial PC on it's own network where I can do what needs to be done. When it needs to be done.

    We actually rate our IT department as a project risk. The less involvement...the better.

    So. It is a real pain but the alternative is worse!

  3. Everyone will have their own methods and solutions to this one. It's an old problem with many equally correct solutions.

    If you give an example stream and header structure we would probably be able to justify each approach better and you could pick the solution that best fits your preferences.

    I find, generally, the best option, if possible, is to find the super set of the protocols and choose a display method that can cope with all of them.

    what do I mean by this...Well...

    Lets say your devices both send a header consisting of a command byte, a length byte and the payload (nice and simple). In device 1 the length byte is 2bytes long but in device 2 it is 4 bytes long. The length byte of both devices can be represented as a 32 bit number so you would choose that to display the length. Just in case the hardware engineers decide to use a bigger length in the future you could even go for 64 bit integer.

    Now. slightly different (but following the same approach).

    Lets say we want to represent the command byte with human readable strings.

    We could use a menu ring (since arbitrary and non consecutive values can be assigned to its strings). We could then assign each string with the value directly from the command byte - job done for device 1. Now there are two ways of coping with device 2 depending on how much similarity there is.

    1. If most of command bytes are exactly the same and the extra ones are just extensions to the original protocol (device 1, MkII) then we have already done most of the work and we only need to add the extra values to the menu ring.

    2. If the command byte of device 2 use the same values as device 1 but mean completely different things (usually different devices) then add...say 100 to the command byte and assign the menu ring strings for that device command byte +100.

    So. 2 devices, 2 different headers and we display a menu ring and a U64.

    If they add more commands...we just add to our menu ring. If they change the number of bytes (up to 8 anyway), we don't need to change anything. You can extend this for the payload too (up to a point ;) )

  4. Hmm. Not sure about getting screwed (it's not that expensive) but I have complained many times - every time I upgrade in fact.

    That said, I'm not talking about the Serial Key (I've got one of those that covers everything) I'm talking about the activation codes since the development PC isn't connected to the internet

    I have to phone up NI and (always seems to be a girl called Sam.....lol) they look my details up and maybe a day later 25 e-mails come through with the activation codes which I then have to get to the other machine. Real pain in the proverbial 2-3 times a year especially if they miss hear the computer ID :P or I haven't upgraded all the items!

  5. Or download the password class in the code repository ;)

    From then on (simplest) its just a case statement with an exit function in the false frame if the password fails and your sub-vi in the true frame if it passes :)

  6. QUOTE (khokhar @ Apr 15 2009, 09:10 AM)

    Thanks and I liked to add that the software I want to access is already loaded and I have method to control it from outside. I just want to know how to access a software when it is running on a computer using LabVIEW.

    Under windows methods such as DDE (Dynamic Data Exchange) or Automation Servers can be used to communicate with things like Excel, Word etc. It enables you to access methods and properties exposed by the application (including things like save and savAs). If you search the net you will find examples for Labview and there is The Report Generation Toolkit which enables interaction with Excel and Word amongst others.

    BUT.

    Not all apps expose their internal methods so it really depends on the program you are trying to control. If the program uses a proprietry file format and does not expose any methods then you are stuck. The other alternatives are to recreate the file format from within Labview (or any other language for that matter) or cludge it by sending key strokes and mimic a user but I hate this method with a vengence and it can be very unreliable.

  7. QUOTE (Neville D @ Apr 13 2009, 09:03 PM)

    I have also used cFP for testing Train Valves, machine control and factory monitoring (many moons ago now). I disagree you are paying for robustness and ease of use. I think you are paying a premium for the NI name. For most of my applications it's the channel count vs cost that is prohibitive. I find dumb 32channel Gigabit Ethernet digital/Analogue IO is far more cost effective and easier to manage (IP65 compliant @ £600 all in) than any of the NI solutions. Even a PLC is 1/3 the price if you really must have real-time.

    QUOTE

    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

    NI PCI cards are cheap, reliable, have high channel counts, easy to use and I go for them every time. But for remote acquisition there are far more cost effective and better solutions out there if you have the courage to step away from the warm fuzzy NI bubble.

    QUOTE (crelf @ Apr 13 2009, 09:21 PM)

    Make sure there is a
    requirement
    to go wireless - some sites specifically rule-out wirelss (military, standards comissions, etc).

    Amen!

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.