Mads

Thanks for the tips guys. I had looked a bit on the MikroTik solutions already...but we'll see what we'll end up doing. For now I've set up the second port to automatically get reconfigured based on the IP of the primary port. That too took some effort (NIs System Configuration API came to the rescue) and it's not a good replacement for DHCP...but it helps.

We have embedded a cFP-2220 into an instrument that should have two network interfaces, however both of them *have* to be using dynamic IP addresses, and this is not supported by any of NIs controllers. The secondary port is always static. Adding a second controlelr just to get two Ethernet interfaces able of running DHCP is not a good solutionI'm thinking that perhaps we could find a router (?) on a tiny board - that could act as a DHCP client in one end, and NAT the traffic to the secondary port of the controller - set with a fixed IP... (Or we could have only the primary or both ports on the controller connected to this router card. The important things is that from the outside it should look like a device with two different NICs, running DHCP on two different networks...but on the inside it could be just on interface (or two if necessary, but it has to be static IPs on that side anyway then). Does anyone know of a candidate for such a solution, or have other suggestions on how to solve such a challenge? The "router" should be small(er than the content of a PAC) and energy efficient (more than a PAC which typically uses 3,5-4,5 W). PS. In reality the devices should only use dynamic addresses when there is a DHCP server available; they need to have a special(!) feature that makes the fall back to the previously received address if the DHCP server is unreachable...but that is a secondary isse. We have been able meet that requirement for the primary port (see discussion here), but with the second port/an external router that will become an issue again....

That did the trick, thanks François

I have installed UI Tools 1.1.0.9 under LV2011 and seem to have all the other packages that it depends on installed, but the state machine VIs still seem to be missing. When I start the Control Generator it starts to look in <userlib>:\_LAVACR\UI Tools\_lava_lib_ui_tools.llb for Add State(s) to Queue_jki_lib_state_machine_lava_lib_ui_tools.vi but fails to find it...not surprisingly since that llb does not exist. I have JKIs state machine (2.0.0-1), but these seems to be renamed copies of some of the VIs in that package. I could manually replace the missing VIs with VIs from the JKI State Machine package, but then I would need to do this again if there is an update to the UI Tools so it would be better if I figured out why the problem occurs. Any idea?

"The front panel window must include a National Instruments copyright notice. " That must be a joke. How many of you do that? I could always find a place for it in an about window (although I do not see what NI should be doing there in our app regardless of the fact that it was developed in LV), but on the front panel in one of our commercial apps, no way.

Is the portal view gone, or am I just unable to find it? Is it meant to be the "View unread Content"-page? Having one page to go to to see an overview of the latest activity (wheter read or not) across the whole site was very practical.

I'm working on an extension to the modbus rtu protocol. The goal is to make a TCP/IP to Modbus RTU gateway that will allow us to use an existing network client (or at least as much of it as possible) as a user interface for an instrument that in this case only will be reachable by serial communication via an acoustic modem (i.e. low bandwidth+high latency). The instrument runs LabVIEW RT on an embedded fieldpoint controller.

Does anyone know if/when/where the 2011 Platform DVDs will be downloadable/out? Creating Volume License Installations gets very messy if we have to base it on anything other than the platform dvds...

Most of the software I make have different levels of access. I also need to allow the customer to turn off all file IO and print options. Logins should time out after a while in case someone has forgotten to log off. One of the easiest ways to achieve this is to include a key in the tag of all menu items with restrictions, buttons etc- and then either automatically grey out and disable these (you can write a generic VI that scans the GUI for these when a window is opened) depending on the access of the current user, and/or filter any events if the key in the tag/name requires elevation. How easy this is to implement in your code depends on how the GUI is handled. I typically put the GUI handling in separate VIs if it is of a certain size and complexity, and this makes it easy to apply access rights checks on incoming events. A user configuration panel is nice to have, unless you get those by other means. I have one that allows me to give users local and/or remote access to the system. The in-built server then checks the user list if it gets a session request from a remote client. The same GUI offers the possibility to turn off user checks locally, in case the server is not running anything else and is sufficiently protected by Windows.

I did not include the scope in the test. To use the variant attribute to get the sort and search we need a string key, not a cluster. This should be easy enough to fix though, either we could add the scope number to the name, or by flattening the cluster. I have not tested that yet though. Now all you need is a script that updates all the polymorph VIs :-) There is no hit on the constant name lookup as a check for that precedes the search in the list of refnums.

As before in 1.1 when the linear search was used to find the register refnum. The linear search is just a bit slower in absolute terms, but with 10000 registers this slowness has extra impact due to the combination of having a large list to search, and having to do it so many times... In the test I changed the register name on every call so it is a worst case scenario. The very first run takes a bit longer than the quoted times because of the array build though (that part could perhaps be sped up as well by expanding the list in chuncks instead of on every call, but that's a minor issue).

Yes, the way polymorph VIs work in LabVIEW I can definitely understand why you do not want to update the VIRegister library again. In most cases the current implementation will be just fine. Thanks again for the work. I did run a quick test to see what kind of performance I could get if needed though. To simplify the change I skipped the scope part and just used the register name as the reference. Updating 10 000 booleans with the same node used to take 1,5 seconds, now it runs in 39 ms.

Thanks for the update . One first comment: Calling the same node with varying register names works now, but it is very slow. If you use a variant to store and look up the index of requested queue (instead of using the standard search function) the use of the cache will be much quicker.

You do not need to open the block diagram, just run the Lock.State method on the VI. You can run the Get method first if you want and if it is locked you can run the set method with unlock as the new state and provide the password you have... If the password is wrong you will get an error, if it is correct you can lock it again if you want and go to the next VI.

Describing architectures can be quite a task. I'm sure the designers behind the CVT e.g. could mention some intended use cases for you, but OK. Let me first give you an overview, and perhaps I can describe something more concrete later if necessary: I typically make different types of monitoring systems that consists of a server that runs 24/7 on an oil rig somewhere and interfaces with the local control system - and remote clients that connect to that server to monitor the situation or do analysis and reports. The server (on a PC or PAC) is configured to poll data from a number of sensors through different types of communication interfaces, it does a number of calculations on the data (new calculations can be added during run-time), logs the trends and system alarms/events - and offers remote configuration, current values, and historic trends to a client counterpart - or via web pages through a web service. A bit like a SCADA/DCS, but more specialised. Most of the applications came in their first version in the late 90's. Back then a main part of the server was its modbus interface to the main control system. All inputs and outputs of the system would have a place in the modbus registers that were read or written to by one or multiple control systems. The existence of such a central and globally addressable memory space made it easy to use it to share data not just with external units, but internally as well. However this would mean that everyone needed to know the modbus address of the data they needed - or be able to use a middle-man that would know that address if given a name e.g...Using modbus registers for something like this is not exactly ideal as there are data type restrictions, scaling is involved etc. but these are obstacles we could live with. I've since then moved away from using the modbus register this way as I do not want to couple things like that, but the idea of having a centrally accessible register of data lives on... If a new calculation or device is coming online it typically needs access to data which may come from any part of the system. If all parts of the system had an interface on its own which allowed others to poll data from it when needed (and ideally this would be a generic interface so that it would be supported by all others), then that might be a way to go, but they do not (some could be redesigned, but it is not very practical to impose such a requirement on all components) - and even so the consumer should not need to know anything about who produced the measurement, just the tag (and data type) of the measurement. The only thing that can really be made sure is that the current data will be available in memory in a "database", and historic values will be available from disk in a log-file/database. So let's say e.g. that the customers asks us to use data from sensor x, two values coming in via OPC, a value from the modbus link to system Y...and produce a calculated value from those variables that is accessible by all other parts of the system. We do this by providing a middle-man which can take in a list of tags and outputs the data we need, and the calculator writes back the results to the same middle-man by providing a tag and the value. This way the calculator (or other consumer/producer) only needs to be configured with a set of tags and a formula. If only current values are required (most of the time this is the case), the middle-man is an equivalent to the Current-Value-Table, which is what I'm proposing that NI develops to be as efficient as it can be because implementing it with the tools we have available now results in a number of performance issues (as discussed here related to the VIRegister and on the CVT site). I've also described this as a type of global that you can create when needed and access by name, but that description might confuse some.

I think Steen sums it all up pretty nicely. My own two cents: If you cannot lookup globals programmatically by their name (basically a simple internal database) then the only value added by such a library seems to be that you can add some flow control to the global (error terminals e.g.) and can hard-code things part textually by typing the name instead of using your mouse. The latter two are both nice features which should be part of the standard globals in LV, but they do not address the need for scalability.

I see it was only added as a feature request so I guess that's why it has not been included: http://forums.openg.org/index.php?showtopic=1117 Version 4 does not include the manual solution with a format specifier input on the read section or ini cluster either. However that would not be a good solution because then you would need to open the file and check what decimal sign is used in it prior to running the read * cluster function.

When I saw this release and the statement that all reported bugs had been fixed (including one described as a fix for custom decimal signs) I thought that the bug that prevents it from correctly interpreting floating point arrays in configuration files created on another machine with a different decimal sign had been solved as well, but that problem is still there, right? I had hoped to be able to ditch my custom version of Read Key (Variant) that automatically detects what the decimal sign is in the file and adjusts the format specifier accordingly

One thing I noticed is that you cannot use one write node to write to multiple registers without risking that the previous registers are lost. As long as no read is opened on the given register the write is the only place the queue ref is open, therefore the queue is destroyed when the write node runs a release when it switches to another register. The release node does not have the force flag set, but the queue is still destroyed because no other reference to the queue exists (necessarily). If this is the case then I think it would be more useful if you the destruction had to be done explicitly. The test scenario that made me see this behaviour (which I did not expect, but perhaps it is intentional?) was that I planned to do a double write to 10 000 registers and then a double read of the same registers, and time the 4 operations. The reads turned out not to return an error, but they would return all but one register with default values (i.e. a DBL would return with the value 0 instead of the value I had previously written to it). Now I only ran through this quickly so I may have overlooked something and gotten it all wrong...However perhaps you can correct me before I come to that conclusion myself :-)

This looks like a smart take on of what NI has posted as a "Current-Value-Table Reference Library". They have used functional globals to store the data instead of queues which makes it easy to access the list of available registers, debug etc. One of the weakest points of their implementation is the slow search it uses to look up the "Register Name" (they could use a binary search instead or use the search capability of variant attributes to dramatically improve this, but your approach gets that part for free from the queue functions). Perhaps the two efforts could be joined? PS. The polymorphic VIs do not have the "Allow Polymorhpic VI to Adapt to Data Type"-flag set so they did not work as I expected in my LV2010.

No, I'm not thinking about the System Replication software. In our case the PAC will be typically be a few thousand meters subsea so it is definitely risky. The startup executable needs to be a bootstrapper which will unload and load the main code dynamically. That way we can ensure that we get another chance if the new software fails...

Your window manager could monitor key events, and regularly check the FP.Open status of all VIs in memory. The default state of the window manager would be to poll the positions of the open front panels (and only those), keep a log of their correct position and move the windows back if the position has changed but has now settled* (and they are still open). (Ideally there would be a window move event for this that you could set an event structure to respond to, but there is not...). If the user hits F2 the state is changed to an ignore mode until F2 is pressed again - in which case the monitoring state will automatically correct the positions back to their original values again... On start and every 1-5 seconds from then on the window manager will run through the list of VIs in memory and update the list of VIs it should monitor. I did a quick test now with 750 VIs in memory and checking their FP.OPen property only took about 40 ms on my machine so it should be doable (the CPU load was not bad either). It is not required that you know which window is currently active. * You could reset the position immediately when a change was detected but that would probably look extra messy so I would rather wait another cycle to ensure that the window has settled, before resetting it...

I need to make the same thing for PACs and the PAC only runs one application so it will have to replace itself (because no network interface will be available - the new app will be transfered on a serial link). I thought I had seen a framework for this somewhere on ni.com earlier, but I cannot find it now. On the PAC it should be rather simple though. All this functionality has to do is to pick up the new file(s) once it shows up (or it is asked to), move them to their proper location (replacing the old executable etc.) - and then do a soft restart of the device (it does get a bit more complicated if such a restart is not permissible though; then the main app will have to be a dynamic launcher that graciously jumps from the old to the new code without interruption). The part that transfers the file is a separate issue.

Kudos just added to that idea. Thanks Ton.

How are you supposed to add an xcontrol to your user.lib / LabVIEW IDE? If you just copy the xctl file and its support files into user.lib the user.lib palette will get populated with the support VIs, but not the control? Should it not be possible to add an xcontrol to your library of controls just as easily as adding a standard control? In my mind the xctl file should contain everything and should show up as a control on your palette when dropped into the lib folder, but is there any such functionality today? PS. There are many x-controls that could have been part of OpenG e.g. (like the IP address string control, the intellisense string control (I think I picked that one up here once, but it is gone now)...but perhaps its due to a lack of support that they have not become that commonplace in toolkits etc.?