GoGators

<br />Woo Hoo! I Win! <img src="http://lavag.org/public/style_emoticons/default/laugh.gif" /><br />

I have to say the editor is not bad. I wish it explained more about the concepts of UML. Other than that I have just peiced to gether what I could get from free web pages. But the tool seems to line up well.

I was pretty sure that a QSM, no matter what you did, was going to difficult to model using Meally-Moore state machines. The reason is that the Queue essentially makes it event driven, and that events break the predefined transition from one state to another. The way I look at it is with the three cases below.

1) Basic Case. Enqueue state A, state A is processed, wait for next state.

2) Compound-State case. Enqueue state A, state A is processed but at the end of the state it enqueues state B. State B is processed, wait for next state.

3) Interrupted Compound-State Case. Enqueue state A, state A is processed but before the state finishes state C is enqueued, at the end of the state A it enqueues state B. State C finishes. State B finishes. Wait for next state.

Essentially that could go on forever with events queued up, so that nothing processes sequentially like a SM needs to be modeled, and every thing is at the mercy of the queue. I would say to enforce the flow of the program if you need to model it.

If a Sequence is running only allow states to be queued up to a secondary queue (or more). That makes it so that sequences must finish before moving on to other operations, thus the wait state must be preformed before operating on another sequence. I think that makes modeling much easier. Drawback is that new events have no priority and you have to wait for sequences to finish before responding.

Event based modeling is difficult, and always makes me do star-type diagrams.

http://lavag.org/top...classes-for-85/

Thanks for the link. I read all five pages then realized I should look up AVL tree. I should have specified it needs to be bi-directional and non-binary. I am trying to make the basis of a configuration data-structure (or any other tree with non-restricting features), and it seemed like a good starting place. The idea being if you want to represent a file-folder structure you could with it. Then you would use the tree control (or multi-column listbox) as a way to visualize the data (much like the custom probes I made).

So is a AVL tree similar to the problem I am trying to solve, and I can't visualize the problem correctly, or am I doing the correct thing with my code.

On another note this might be the basis of making a custom run-time NSV deployment tool (obviously being tied to a project is little restrictive).

or your application will crash altogether...

Definitely should crash. At least that is what it does to me all the time.

If you want too log your memory usage here is where their are VIs to do it. In LV2009 they are native.

http://zone.ni.com/devzone/cda/epd/p/id/4952

LAVA,

I have a need for a tree data structure in LV. Rather than using a a tree control on the front panel and using its methods and properties to manipulate the tree I decided to see if I could do it using LVOOP with DVRs. In the end I have something that looks promising, but I was wondering if anyone has tackled this design pattern yet.

TopLevelTest.vi is the top-level. There are custom probes for the tree and node class to see the data better. Also since that was my first UML design, if anyone wants to critique it that would be great too.

Tree.zip

Thanks all,

I think I'm gonna start with StarUML and see if I like it.

I have noticed some people posting their UML to demonstrate what they are trying to do with native LVOOP. What tool are you using and is it free? I tried finding it on another post, but the search didn't seem to come up with anything.

The reparenting functions in the Win32 API are very simple (they basically just need the handles of the parent and child windows which you can easily get using the window name or even some private properties in LV), but there are some gotchas. If you search both here (although here the search sucks and many of the old attachments are missing) and in the NI forums for "MDI" or "parent window" you should find some examples, as well as some details.

Thanks for the MDI search term. As soon as I had the name so many more forums were useful. I guess I like this one best since the first example is simplest:

http://forums.ni.com/ni/board/message?board.id=170&message.id=113425&query.id=1089553#M113425

The link looks broken. I have reported it to the moderator. Any chance you could repost.

Done it heaps of times - used a combination of user32.dll calls to parent items to a workspace window (look for the SetParent function), and templates + scripting to dynamically create the items and their components.

Any chance you have a bit of code that could demonstrate it? If not I'll start digging around.

Does a faster PXI-RT processor reduce deployment times?

I think the bottleneck is the network cards. A new PXI controller will have a gigabit port and the 817x has a 100 megabit. Just a best guess and not a benchmark

I have a need for a workspace in an application I am making. I was wondering if anyone has done this, or has some basic ideas. A workspace is similar to the concept of a subpanel, except you can insert multiple VIs into it, and they can float around on their own. The best way to put it is like excel. You can view many spreadsheets simultaneously in the workspace, but they cannot leave the workspace. The sheets can be minimized but they still exist inside the workspace.

As a side question to LAVA, is there an "control or indication repository"? I have made a bunch of common ribbon-type buttons that might be nice to give to the community. Stuff like a Exit button, Save, Busy, the sort of thing that makes an application look more stylish and modern without being too flashy.

It sounds like what you want to do is create a source code distribution. There are options in the build specification for including information in the user.lib and vi.lib.

Hope this helps.

Jason

Jason is right. The only thing you will need to copy is the project since source distributions are target based and not project based and it can drag all the interesting (vi.lib, user.lib, and inst.lib) stuff over. Just be careful not to include files you don't need, because cross-linking problems can be annoying.

If you want to go in such a direction I would actually recommend you to look at the Design patterns NI has released through its System Engineering group. They have some very nice tools that do a lot into this same direction. If I would have to start again from scratch I would probably go with that eventhough not all components are available in LabVIEW source code. But at the time they released that stuff, my system was already developed and running for my needs and it has a few technical advantages and also the fact that I can go in and change whatever strikes my fancy for a new project is in extra bonus.

I work in SE for NI. I was making a webservice based communication for the CVT (was going to call it webCCC), but since I don't think webservices are quite there I am putting it off. I had heard about someone who had done it with variants and variant attributes, and was fishing to see if anyone had posted something like that. Maybe for a different thread.

I would feel quite unhappy to have a WebService inside my RT control application. It's advantage of easier communication with other parts of the RT program, seem to me outweighed manifold by the extra complexity that creeps into my RT process. IPC through shared variables or TCP/IP communication (my preference) may not seem so elegant at first but it is really not that complicated to implement, especially if you have created a template of this before

I guess the bonus of a webservice is it meets RESTful architecture, connection management, security, and a little help meeting internet standards (XML, JSON, etc.) Not being able to debug on RT, and separate application space lowers the advantage of connection management and RESTful (state management).

My RT system design looks a little different in details but quite the same in overall architecture. It originally stems in fact from the need to have an easy communication link to the host for monitoring some or all of the tag based variables. But I have added over time extra means to also communicate with the internal error reporting engine, to start, stop and restart the entire process, to update its tag configuration, and with a simple plugin mechanisme to add extra functionality when needed.

How do you manage your tags? I ask because I have been do a lot of that lately. Originally I got into webservices trying to make the communication layer for my tags a little better, and meet more standards.

I am creating a list of allowable user IPs in ni-rt.ini file, however after each deployment on RT target this file is been overwritten all over again.

Is there any way to protect ni-rt.ini file from modification during the deployment on RT target ?

Are you setting the user access in the project or manually ftping the ni-rt.ini file over? I would say the correct way is through the project.

Since the Web Service will have to modify some of the data used in the Main Instance I was wondering what the best way of exchanging data between these two application instances would be.

If this were two VIs in the same Application Instance I would use queues and notifiers but is that possible across instances?

I guess I could use network shared variables deployed on the cRIO but I was wondering if there was another method.

Great post by the way. I was trying to do this exact thing for my application. The way I ended up doing it was to open up a reference to the other application using VI server, then reading and writing to controls and indicators that way. You could also do it using TCP IP to localhost. Both of these are not great solutions, but they did work for me.

Ultimately the problem of WebServices on realtime targets is that it does make sense to have them in their own application instance. A control system does not typically act like a command-respond system. I think the restful server needs to be more tightly integrated with the rtexe, rather than separate. Might make a good idea market.

I'm not sure how time consuming it would be to create 5 translations for 300-400 controls though. Also, what if (as in my case) the developer is not the translator?

Well, it is not really translations of controls, so much as resources. Naming the resource and control the same thing makes it easier on the developer though. Looking at the article would probably clear that up. The translator and the developer can be different people, as long as they have agreed upon the resource naming convention. I assume that's how most applications provide run-time translations.

Looks like your doing it the hard way

It certainly took some effort to make the editor. Hopefully it gets some use. The nice thing about a single file is transportability. Also grouping translations into resources helps with accessing data if you want to change the language setting at run-time. Plus the editor helps you organize resources into folders, so all the controls for a single VI can go into folder. Just makes it pretty.

I made a Localization Configuration Editor and for NI week this year.

http://zone.ni.com/devzone/cda/epd/p/id/6257

It helps you to create/edit a resource file with all your translations. Then there is a library that helps you pull the information from the resource file into your application. Its all open source if you want to give it a try.

Would seem to me almost a perfect solution, provided the schema is not to complicated.

Rolf Kalbermatter

The schema is not too complicated. To be honest I just wrote out a bunch of files on a windows machine, and recreated what they wrote out (simple read/writes). The documetnation on MSDN is pretty poor. I'm starting to think an XML parser on a real-time target would be a useful feature.

I published the article and examples here:

Supporting Relational Databases on LabVIEW Real-Time

Feedback should go http://forums.ni.com/ni/board/message?board.id=deployment&thread.id=11

Sorry for not looking over these posts earlier.

Like Christian_L said the VxWorks version is up and running. A simple LV API is already made. Still working on the PharLap version in CVI RT. Since I am still working on it the code it is still messy, but if anyone needs the VxWorks portion right now I can post what I got.

As a side note:

From my original post I ran into an interesting idea for #2. The file format I choose was ADO schema XML. It turns out the Database Connectivity toolkit has some Save/Load Recordset VIs in the Utilities palette. These Write and Read in XML. If you reverse engineer the schema you can make your RT target write files that can be read into database using the toolkit. Just something I noticed and implemented if anyone is interested.

I thought that this JKI RCF plugin was so cool that everyone needed to see it. Thanks, Jeffrey for this cool tool!

This is so awesome. I was in the middle of making it myself.

I'm just slightly confused what you mean to do with this. Do you mean to have your LV program transact with the local SQLite instance and then clone the data on the RT over to another machine, or is there functionality for network databases in SQLite that I don't know about?

Sorry. I should have given a little history. If you look through old lava posts, people have talked about doing an OpenG project where they make SQLite work in LV. The idea was to make a DLL, which would work for PharLap RT controllers (essentailly RT-PXI, and some older FPs and cRIOs). I don't know what happened to that project, but I didn't see anything on OpenG.

And yes, since SQLite is ideal for embedded systems, store the database in a single file locally. Since SQLite is connectionless, I would assume it would stay connectionless.

At the request of my sales force and some customers I am going to be writing an article and examples on NI Real-Time targets and Relational Databases (Historical databases seem to be pretty much covered by Citadel). The idea is to generate some starting points, an provide some examples on how-to. After speaking with some peers I have some good ideas, and wanted to bounce them off you Lavanians (do we have a name for LAVA posters?)

Before I get too deep I have to ask the most important question. Is this useful. So has anyone out there needed Database support on RT? Ideally there would be information about every topic you could come up with, but the reality is that if no one needs it I am going to use my time on something else.

OK assuming someone needs it, there are three scenarios I am pretty sure I am going to talk about.

1) The current NI recommended way to have databases on RT Targets is to make a communication layer between your RT and Host. Then have the host do all the real database operations, and the RT is just passing the information along. I have an example that has the RT send data over TCP to be recorded to a blank .mdb using the Database Connectivity toolkit. Then after some time the RT target requests something like 100 records to use in decision for state machine. Pretty straight forward, and shows that an SQL statement can be passed from RT to host without any translation of data on the host-side (in otherwords the host does not need to know anything about the data, it just works with variants).

2) The RT target makes files in a specific format, then the host retrieves the files periodically and places the data into the database. Some FTP operations, and thats about it. The file format is tricky, so I am still deciding on what to make it.

3) The coolest one by far, make RT targets actually support databases by porting SQLite to Pharlap and VxWorks targets. There has been some talks about it but I didn't see anything definitive on OpenG. Currently trying to get SQLite to build as a DLL in CVI.

SO:

A) Anybody actually going to use this stuff, or am I wasting time.

B) Does the three above meet pretty much all the scenerios you can think of?

C) Anyone been working on the SQLite thing lately?