ShaunR

Thanks, for the tip, but if i put my heartbeat in the timeout event, where should I be monitoring the port for received messages? I would have just put a short timer on the timout event and listened for bytes at port, and wrote them to my terminal as I saw them, is there a way to create a "bytes at port event"?

Receive in a separate loop. The Event structure is your "command" loop and the receive loop is the "response".

And for extra brownie points; do all of the commands with 1 write vI.

Don't normally go in for this sort of thing....but

Front slogan: Class - Simplified

Rear slogan: Simply Class

Or maybe thr other way round..

Hi everyone, I'm new to the board and pretty new to labview. I have a simple serial messaging protocol. I need to create a tool that will essentially be a terminal tool with buttons that will send out 5 or 6 manual commands. The commands have start character and end characters. It will also need to send a status message at some interval and be able to send the same status message on demand.

I was thinking about using a state machine for this, however the adjustable rate heartbeat message and how to handle that in statemacine is kinda jamming me up and maybe i'm trying to be too cute or am just going down the wrong path in general. also searching around i was unaware of visa events, would this be an appropriate use of visa events for the message reading or am i better off just inspecting each byte and acting accordingly?

any tips would be appreciated.

Use an event structure and just send the heartbeat in the timeout case (wire a value to the timeout). Your commands will map to an event case, so just send them in the appropriate case. That will achieve what you want with very little effort and you can always pull it out into a more elaborate approach later, (you will still probably use the event case for the UI regardless). A state-machine seems a bot overcomplicated for your current spec.

Confirmed (2010 x64 Win64).

No problems on 2009 x64/x32 on win64.

Fantastic sleuthing to have tracked that one down.

Hi Rolf - thank you for the reply. The C# programmer tested the DLL pretty thoroughly, including downloading LabView 2011 and making sure LabView could call the DLL. That test passed at the development site in Mexico. But when the developers in China tried to call the DLL they get the error. I'll forward your comments to both teams (in Mexico and China) and if they have any questions or comments in response, I will post them here.

Was the assembly tested on a windows box with a Chinese or Japanese localisation? My first thoughts with Asian-only issues are the problems (and Labviews issues) with Unicode string handling. The problem you have (as Rolf is saying) is you have a black-box that is't happy and no way to tell why it isn't happy (Labview can only tell you it isn't happy).

Presumably the author of the assembly has a test harness of some description. Can you send that out to China and see what error log it produces (if any).

Firefox and Opera disabled websockets. Server-Sent Events is still enabled in Opera.

You can enable websockets in Opera by going to the following url "opera:config#UserPrefs|EnableWebSockets" then scroll down and save the changes no restart needed.

Websockets can be enabled on Opera Mobile with the same url as the desktop version.

They both plan on bringing back websockets when the security problem is fixed.

It looks like Google and Opera are working on it. http://www.ietf.org/...t/msg07296.html

Also you might want to use BufferedRendering for SVG, it helps speed things up.

Firefox can also be used. FF4 is shipped with web sockets disabled but it can be enabled from the config page

Enable Web Sockets

For internet explorer you need an additional (experimental?) plugin which isn't really any better than NI's approach and a real pain since it is still the dominant business browser.

IE web sockets plugin

Maybe i wasnt explaning my self or i could be wrong so hear i go i understud that dll or not sopported by mac, Im doing a DAQ hardware and labview is my controler in software is there a way where i can use my pic on mac to comunicate to labview to send and recive info thanks sorry for my bad spelling..

Yes. Absolutely.

All the VIs you have downloaded are based around uploading the firmware to the PIC. If you have this already then once you have programmed the PIC with the USB commands that you want it to respond to you can use the LabVIEW serial comms VIS (VISA) to communicate as if it was a normal serial port (see the simple serial example shipped with LabVIEW).

See here about using PICS with virtual serial ports.

Hi i found this files on a other fourm to be able to call the pic from labview can any one tell me if this could work on mac im still trying to make my project work cuz all i have is a mac and realy hate windows thanks.

DLL in labview

I'll reiterate. DLLS are for the windows platform. So no. It won't work.

there are 2 aspects to using pics.

1. Uploading the firmware (bootloader and your program either using a PIC programmer or specific software).

2. Communicating with the firmware once you achieve No1 (usually as a serial port)

To achieve No1. You have to use the toolchains supplied from the manufacturer (I use HiTech as it happens) or some open source equivalent. The VIs you are downloading are merely wrappers around the manufacturers API for communicating with their PICs that are "blank" so have no USB support as you would consider it. (LabVIEW is not a PIC programmer). Lots of people have windows and microchip supply the DLL for windows and some people have written the wrappers to use this DLL for uploading the bootloaders and firmware rather than using one of the myriad of other tools people have written.. For the MAC they (Microchip) would need to supply a "framework" or dylib which would enable you to do the same on a MAC with LabVIEW.

Maybe this page on PICs with the MAC and Linux will help.

If you take a look at this awesome video tutorial I posted on my VI Shots blog. You can see an example of using reentrant VIs to create multiple user interfaces that look the same but handle different data. It doesn't contain any classes but it's a small change to add classes to this design pattern.

Click here to watch the video.

Good video.

This is basically how all my software works.

I don't see what is problematic, so any idea is welcome.

I've never experienced this problem so this is a wild guess. But spurious issues in "ini" files can be a symptom of excessive path lengths. Try deleting the line for "RecentFiles.pathList", "NewDlgRecentMainTemplates.pathList" and the quikdrop ones.

Hi to all im trying to make my demo board i found in this page Ston10.com and trying to connect it to my Macbook but it dosent soport the dll file given by microchip it says error the file you selected is not a valid library, can any one help me thanks ill send the VI im using.

DLLs are for the windows platform. If you are using the MCHPFSUSB, I've never seen Microchip support for the MAC, but you never know.

No, more like details -> Tables will default correctly using the IN (you said they wouldn't above).

Ok. Just for you

I mean a Multicolumn List Box (which is a table to a simpleton like me ) rather than a Table Control. So yes you are right a "Table Control" does work. Not all table-type controls do though.

Not fool-proof is exactly the problem.

However the API is quite interesting. Any chance you have a pre-2009 version lying around? (8.x would be nice!0

Wow. For once LabVIEW didn't crash when saving to a previous version.

I need to get the HW serial number from the chip. I have seen posts about it and some talk about example code, that's why I thought someone in the LV sphere could have already done it.

I flirted with it a while back (its on here somewhere). The issue is Admin rights. I never got around to revisiting it.

Yes! I kept reading over and over on LAVA about this wonderful thing called "plug-in architecture", finally researched it, and discovered it was something I'd been doing for quite some time -- I just didn't know the fancy name for it. I will admit to some concern over potentially being stuck by not knowing "correct" terminology when/if I ever get around to taking any of these certification exams.

Perhaps we should design a BS Bingo game for LabVIEW

Get that on the LabVIEW Idea Exchange! Unless it already is, and in that case: link me to it!

I don't know if it is there or not. I don't visit the NI sites much any more since it kept asking me to verify my details-so I don't bother now. But we have over a year to argue about it before it is likely to be considered

That is not quite correct.

Tables will be cleared (or rather, set to Default) using that IN as their datatype is a 2D Array of Strings.

Combo-boxes have a String datatype so that will Default the 'selected item' (which is what the datatype refers to) not the actual list data in the combo-box which is persistent and accessed through e.g. Strings[] PN.

IMHO this behaviour is expected and should not be changed.

Well. We are about to argue about semantics.

I didn't say what it should do, just that I find it irritating that it doesn't and pointing out that if the OP uses it, it probably won't do what they (and I) expect for those controls.

Note that this invoke node will not clear tables or combo-boxes which I've always found infuriating

Hello All,

<snip>

Zaki Chasmawala

Senior Engineer - Training & Certification

National Instruments

Well said.

I personally think people get hung up on the terminology. I view the NI certifications as expanding levels of remit that closely follow a typical career path as you take greater responsibility over more of the project life-cycle. You start off with a general knowledge about LV (CLAD-demonstrate you know what it is) then progress to detailed implementation (CLD-demonstrate you can write software) and for the CLA it expands into requirements decomposition. (that's where I see the grey area between technical and project management begins) If you demonstrate competency in all these areas then you could also call yourself a software systems engineer, senior software engineer, chief developer, software technical authority et al. "Architect" has always seemed a bit, pretentious to me. At this level, titles don't really mean much (I notice you don't call yourself an architect ).

I'm pretty sure that next time round, Daklu will probably get one of the highest scores ever in the tests now that it is clear what is expected. For most of us, examinations are rare occurrences and we may perform better under pressure in a management meeting (that we deal with often) rather than in a timed test..

Well. I'm coming in a bit late but I'm a bit surprised that there's no discussion of tagged-token/static dataflow or even actors and graphs. Yet this whole thread is about dataflow ?

I don't know specifically because I have never given it much thought and only have a cursory understanding since it's not my remit. But if I were to catagorise labvierw I would say it is either a tagged-token dataflow model or a variant thereof (hybrid?). Asking whether it is "pure" or not is a bit like asking if the observer design pattern is a "pure" design pattern.

Not a consolation I know, but you're not the first. And definitely won't be the last. Of all the NI exams. The CLA is the one where exam technique weighs heavily in the results.

You can nail the requirements and documentation by spending 1/2 an hour writing a well rehearsed scripting VI and cutting and pasting the requirements into a text file As Crelf said. "Give the examiner what they want" (or in this case, the Requirements Gateway).

But it has no provisions to support true realtime operation so you can't call it a realtime system.

Hmmm.

Not sure I necessarily agree with this. M$ has been touting CE as "hard real-time performance" since version 3.0 and the term "real-time" on it's own tends to mean many different things to different people. But here's a report into it's real-time capabilities and a rather excellent web-cast on its real-time features so you can decide by your criteria.

When it boils down to it. There really aren't that many "real-time" applications that are required of an OS in Labview development. The trend is to offload real-time onto dedicated hardware and NI have many fantastic PCI or PCIE solutions for this. Thats why we have seen the proliferation of FPGA. This means tat Embedded Windows is an excellent platform for real-time (or near real-time) applications.

I've actually been using Windows XP Embedded Standard for a couple of years now (not exactly the same as CE). Far cheaper than NI platform products and you can use NIs cards as well as other manufacturers and is therefore far more versatile. Once you get the right initial "image" - Labview runs on it too. We have gone down the route of having small embedded machines for specific task (e.g one for image acquisition, one for motion control, one for acquisition etc) and as replacements (or alternatives) for cRIO. So far, we have not found one instance where it hasn't been as capable. But many instances here it is far more versatile and at a fraction of the cost.

Looking forward to evaluating Embedded 7. But XP has worked so well (with Labview) that it'll probably only happen when we really have to.,

You should feel worthy that your consideration pleases me.

http://youtu.be/Vh78T--ZUxY

Really? You write Mutha Fucken VIs too?

I write VIs Mutha Fucka (VIMF)

Yup. well worth a rofl point. I have seen quite a few of those VIs.

ShaunR's LAVA CR Trim Whitespace VI (Fast Trim) is nominated to be integrated into the OpenG Strings package as it is 3x faster the standard Trim Whitespace.

The author has confirmed this is ok.

You can track this new feature here: ID: 3292424

Sweet.

I'm pleased it is worthy of consideration.

Multi-Functional VI (MFVI) aka Action Engine (AE) aka Functional Global Variable (FGV) that does more stuff etc...

You made that up What you meant was LTWAC (Lazy To Write A Class)

For starters, before a child object can be instantiated, the class must be loaded. It doesn't matter when this loading takes place--it may be when the application starts or it may be right before the object is needed. (Even though we don't have have lazy loading directly available to us, we do have some control over when things are loaded.) Loading the child class loads the child's dd table, along with all the child's members.

Red: I think this is where we are at odds. I think it matters very, very much.

The loading of the VIs in a class is orders of magnitude slower than instantiating an object. One is a disk operation and the other is just allocating memory. The big caveat with classes is that a class doesn't just load what it needs (as it does in classic LabVIEW). It has to load everything in the class - needed or not. Pre-loading these method VIs is the only practical solution to trade the 1 or 2 seconds (say) of disk activity for a few microseconds/milliseconds of execution and repeatability/consistency of calling those methods.

If, however, it is loaded just before it is required. If may be that that 1 or 2 seconds for LabVIEW to load the class from disk is in the middle of a 100 ms timeout, or a timed measurement. Then it is a real problem.

Blue:Exactly.

But the way the DD table works is that it is a list of VI references in the order of of the hierarchy (parent at the head, child appended to end). If we want to prevent the second scenario as described above from happening. then it will have to load the parent AND the children from disk before the call. If it is an overridden parent. then it will have to load the parent, child and all the siblings.

Then dynamic dispatching injects a small bit of functionality (I'll call it the "dynamic dispatcher") between the connector pane terminal and the block diagram. At run time, after an object arrives at Parent:A's class input terminal, but before Parent:A is invoked, the dynamic dispatcher says to the object, "This is dynamic dispatch method #1. Give me a reference to the vi you have listed in your dd table at index 1." The object returns the reference and the dynamic dispatcher invokes that vi. Parent objects will return a reference to Parent:A. Child objects will return a reference to Child:A.

Yes. Absolutely. It returns with a reference. To have that reference it must have loaded that VI. As it cannot load a single VI from a class. It must have loaded the entire class If it didn't know before-hand what class it would need, it must have loaded all of them. Unless it lazy loaded the class when the call was made.

This is one way that I think about what the "mechanics" might be (in the design environment in this case). There are a few ways that the blue box area could operate (they could be sequential, depth first et al.), but it's basically how I see the partitioning between loading. and calling in reference to the document.

From this I think you can see that I believe (I'm only guessing after all) that all classes are loaded before any calls - loaded, not instantiated. I think instantiation is just semantics to keep POOPers happy since I could say that by placing a common or garden VI on a diagram I am loading and at the same time instantiating that VI. In In this case it's just a parent and child. I think that if you override, then siblings would also be loaded. In the image, your "dynamic dispatcher" is the index array element primitive.