Input needed from LabVIEW DSC 8.0 users

[Peter Parker]

Hello,

I'm currently using LabView 7.1 and thinking about upgrading to ver 8 for its shared variables and DSC module (Datalogging and Supervisory Control).  Before i jump ship I would like to ask existing users' input:  I have a VI that monitors different systems, and there are many variables, if you will, that I would like to log when they run outside the limits that I have set.  I would like to log the timestamp and the offending variables.  From the description it look like DSC is the way to go.  My question is can I use my existing VI and redefine or declare the variables, so to speak, as shared variables and have DSC module monitors those shared variables?  Please point me to a tutorial or knowledge base so I can start reading.  Thank you.

Peter

[REM1]

Start by looking at this.

Message Edited by Support on 03-08-2007 09:11 AM

[cs42]

Well, this is just marketing.

It's much more interesting to know, if users experienced problems moving from DSC 7.1 to DSC 8.0. There are quite a few changes to DSC!

As so much changed in working with DSC Tag Engine, it would be interesting how this effects working with the DSC Run Time Engine as well. I gues I'll have to try myself...

[REM1]

Ah, it was not clear to me from your original post that you were already familiar with DSC.

The new shared variable, and its engine, replaces the tag as the abstracted element in the application.  DSC 8.0 does have compatibility code that does a pretty good job of making the new system behave like the old one but it is not perfect in all respects. 

• There are status codes the old engine had that the new one does not.
• You cannot specify that you want an event generated when a user does a tag write.
• Using the compatibility code is, not surprisingly, slower than using the native DSC 8.0 code although not appreciably slower than using DSC 7.1.
• Converting large .scf files is time consuming and the new engine seems to have difficulties with processes larger than ~30K tags.
• The API is different and requires some re-learning of things.

These are the only issues I have heard of personally.  The status code wasn't a major issue - it was being checked to handle an error that no longer occurs.  The large .scf is no longer necessary because of the ability to run multiple processes at the same time and because the alarm system is more flexible but dealing with breaking it up is somewhat painful...not an issue many people are likely to run into.

That's all I can tell you right now.

[Peter Parker]

REM1's answer is a very good response for migrating existing 7.1 DSC code to the 8.0.  I tried to use 7.1 DSC a year ago only to find out that I couldn't use it as it is not compatible with the M-series board (DAQmx).  I just talked to NI support yesterday and confirmed that I can indeed use DSC8.0 with DAQmx.  Also, I can reuse my existing VI without major change (thanks to shared variables).

[cs42]

Does this even mean I can write with two processes to two different databases using the DSC Run Time Engine now?

What I'm a bit concerned about is, that I may need to have to change our way using the DSC Engine. Currently we define a set of tags in the DSC Run Time Engine with a Citadel database attached to it. Most of the data is read from FieldPoint systems and a GUI process might access the DSC Tag Engine, but for some test-rigs this isn't mandatory currently. That way the logging starts as soon as the Tag Engine is started (on OS startup) using the last used .scf automatically. I don't understand yet whether I can use the new DSC Engine the same way or if there needs a process to be loaded all the time.

Cheers,
    Carsten

[REM1]

In 8.0, each process in the engine can log to a separate database.

You do need one, or more, processes to be loaded into the engine to have it handle the data, including logging.  The 8.0 engine is a system service so it launches at OS start.  Processes are not kicked out of the engine on OS shutdown so all processes previously loaded and running will continue to be so.

Regards,

Robert

[cs42]

I waited long for the DSC Engine to be run as service, finally it's there!? Does this mean as well, that my GUI processes (or processes logging to the DSC Engine) don't need high privileges any longer?

And do I really need to write a program for logging now even if I just want to read data from Fieldpoint (or any other hardware) and write it to a database (scaling and so on to be handle by the DSC Engine)? With the DSC Engine until 7.1 I just had to setup a scf to do this!

Thanks for your answers.

Cheers,
    Carsten

Message Edited by cs42 on 01-18-2006 05:52 PM

[REM1]

If you have DSC 8.0 installed the LabVIEW 8.0 shared variable engine will handle scaling, logging and alarming like the DSC 7.1 engine did.  So, if I understand you question correctly, no...you do not need to write a program to handle any of that.

DSC 8.0 provides the ability to write directly to the database without using the engine primarily for those cases where you collect data faster than the engine can process it and you require that all points be kept.

DSC 8.0 provides the ability to have alarms/events not tied to a shared variable because sometimes you need one and you shouldn't have to make a variable just to have an alarm.

I confess that I do not know how the permissions stuff works in 8.0.  I think that your GUI program should not need admin permission, but I am not sure.  If you test this, let me know how it worked out.

[cs42]

Thanks a lot. This makes me more easy about moving to LV DSC 8.

As we do not need to write to the database directly (we only collect quite slow data), I hope the workflow we will use doesn't have to change too much.

Cheers,
    Carsten