Jump to content

gsussman

Members
  • Posts

    10
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by gsussman

  1. We have used HTML templates as ShaunR mentioned as an effective method of generating reports. One of the nice features of this method is that the customer has the latitude to modify the HTML code as they see fit to configure the page look and feel. We provide a list of "tags" that can be inserted into the HTML that our program just does a direct string replace for the data of interest.

    If the requirement is the ability to import data into MS Office or other programs for post processing then CSV or tab delimited text seems to be the least problematic.

    Depending on the level of reporting and data logging that needs to be done, data storage into a database with reporting by one of the many Business Intelligence and visualization tools might be the answer. I have one customer who has done some pretty amazing work with Tableau. I have also heard that Microsoft BI is a decent package as well.

  2. While I can't offer a specific solution to your current problem, the issue of integration with Microsoft Office components has been one of those thorns in the side of developers for many years. The problems you are seeing with incompatibilities between versions of Excel are not something that is likely to go away after delivery. Corporate IT departments are continually pushing new patches and versions from Microsoft which will from time to time break your interface.

    As a general rule I do my absolute best to sway the customer away from direct integration between MS Office tools and the operational LV code. It has always lead to heartache and support issues. Every....Single....Time.

  3.  This is something that I inquired about a few months ago.

    For the current moment I do not think that there is any way to deploy LVRT to a virtual machine other than the NI Hypervisor running on a PXI chassis.

    While I suspect that your need would require the determinism of Real Time, my request was more from a debugging aspect. It would be very convenient to have virtual machines set up for my various deployment targets (cRIO, cFP, etc...) and be able to actually test my code on a VM before going on-site to install code upgrades/modifications. I realize that I would not have the determinism of the actual RTOS when running on a VM, but it would certainly help with debugging.

  4. LabVIEW System Replication Tools

    Take a look at the following link

    http://zone.ni.com/devzone/cda/tut/p/id/3937

    The LabVIEW System Replication tools make this much.....much easier.

    Configure one RT system the way you need it

    Download an image of the system

    Upload new image to as many targets as you need

    I am not sure if the bug has been fixed, however there was a small issue with the built EXE that is included in the ZIP file. It required that the MAC address was the same in order to upload the image.

    If you run the source code version, you can easily modify this behavior to disregard the MAC address.

  5. This one appears to only apply to the new VxWorks based RT systems (cRIO-9012)

    The String to Path function does not operate the same as it does for all other platforms

    Correct Behavior:

    String in: "calibration\"

    Path out: "calibration"

    Behavior under VxWorks

    String in: "calibration\"

    Path out: "calibration\" <---- Note the "\" character is still present

    Depending on your code, it can cause double backslash characters "\\" to be inserted into your build path functions.

    c:\\calibration\\test

  6. I have just migrated a very large project 1000+ VIs divided over 2 platforms (Windows and RT) up to LV8 due to a showstopper problem in LV7.1

    All I have to say is that I wish I had another option.

    I have experienced similar development system crashes when editing, long latencies when performing operations like editing, saving, opening, etc. (feels like my cursor is perpetually in the hourglass mode as well as the telltale GUI thread starvation indicator (all windows go white while CPU time is at 100%)

    Unless you had no other choice, pass on LV8 and wait for a more stable release.

  7. I was wanting to poll the group to see if anybody has come up with an elegant, or even a semi-workable way to maintain compatibility with multiple versions of the many NI drivers that various clients may be using.

    Being that only a single version of any driver can be present on a system can lead to multiple uninstall/reinstall operations on a development system to support a customer who may be running an older version of a specific driver.

    The situation I am getting at is as follows:

    Customer A has a number of like systems running code developed in LV6.1 and Fieldpoint 4.0. The system was implemented and validated when 6.1/FP4.0 were the current versions. They now come back and ask for a small change to the code. The size of the change does not warrant updating all of the systems to the current versions, so for the mean time, that option is out.

    Our development systems are running FP 4.1 which is not compatible with FP 4.0 so an EXE build in LV6.1, with FP 4.1 on the development system will not run on the customer's machine (LV6.1-RTE with FP 4.0).

    Short of uninstalling FP 4.1 on my development system and reinstalling 4.0, which I know works but is a real hassle, is there a better method somebody is using? (i.e. Maintaining a seperate library of functions linked to the previous driver's dll)

×
×
  • Create New...

Important Information

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