Second Time Base in LabVIEW DSC 7.0

Did anyone know, how we can write externally logged data with their own timestamps into the Citadel database in LabVIEW DSC? In Lookout it works fine with the "Logger" Object.

You may want to check out:
http://zone.ni.com/devzone/conceptd.nsf/webmain/5A921A403438390F86256B9700809A53?opendocument
There have been a couple of other posts in this forum regarding its use, e.g.
http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=506500000008000000DB9E0000&USEARCHCONTEXT_CATEGORY_0=_51_%24_6_&USEARCHCONTEXT_CATEGORY_S=0&UCATEGORY_0=_51_%24_6_&UCATEGORY_S=0
=====================================================
Fading out. " ... J. Arthur Rank on gong."

Similar Messages

Installing LabVIEW DSC 8.6 Run Time on Windows XP Embedded flash memory

I'm trying to install LabVIEW DSC 8.6 Run Time on an embedded PC running Windows XP Embedded. This has a small local disk (c), so I would like to install DSC Run Time on a secondary flash memory drive (d). The installer tells me that I don't have enough free space on drive c, but I cannot browse to select drive d. What do I need to do to get this installed?
Thanks,
Josh

The DSC module can't easily be installed to external flash memory. You'll want to move any extra data onto the flash drive to free up space on the internal memory for installing the DSC module.
Mark E.
National Instruments
Schedule a Free 1-Hour online LabVIEW Tutorial with an NI Applications Engineer

Labview 5.1 Executable crashes when I try to run it a second time

I created an executable from some labview 5.1 code I wrote. The code works fine when I run it under labview, but when I created an executable, the code crashes. I can run the code once and it will work fine, but when I try to run it again it crashes.
The coded basic function is to record data displayed on a network analyzer screen. I have the analyzer go into remote mode for data collection and back to local after data collection so changes can be made to the display. When I try running it again after changes were made, the executable crashes.
Has anyone experience this problem?

I have run into this problem a couple of times for different (but similar) reasons.
One was that I used the VISA open and talked to the instrument, but did not CLOSE the VISA session. When trying to OPEN again (second time program is run), the program would crash.
I had the same problem with opening references once. It is supposed to close all references when the program ends, but I always close my sessions before exiting.
Look for OPEN without CLOSE in the program.
Hope this helps.
Rob

C++ Call to DLL made in LabVIEW Fails the second time it is called

I have an application where a C++ executive calls a LabVIEW DLL (a LabVIEW application built into a DLL).
The executive calls and operates the DLL fine the first time (NT, the applications task manager shows LabVIEW runtime runs, then stops when the DLL is done. However, when the executive calls the DLL a second time, it hangs, and the runtime engine never shows up in the applications task manager as running.
However, this only occurs when something like IMAQ, DAQ, or another custom DLL call is occurring. We tried it with a simple DLL that only uses a call to the sound VIs, and it seems to run fine, although as the program called is very short, and the task manager slow, we never see the runtime engin
e in the task manager. We are going to put a popup dialog in to ensure that the DLL is being called reliably, but we believe it is.
We are unable to answer why when we call something that uses IMAQ, that the DLL doesn't run right the second time. We are unsure of the reasons, but believe it to be related to thread creation and destruction in the executive.
If anyone out there has any insight into this, we would be happy to see it.
We will be putting in a formal request for support from NI, but wanted to poll the audience as well, as we know from first hand experience that LabVIEW users often times have more experience with this sort of thing than developers.
Thanks a bunch

> Thanks for the information Greg. There is no documentation on this
> issue, except for the email that we got from NI Support. This is
> quite a new realm for us and NI alike. We would like to know what
> your experiences have been on this subject. If you have a bit of
> information, perhaps we should suggest a topic. As I said, this is a
> new frontier for LabVIEW, and there are a lot of things that NI
> doesn't know, and I'm sure a few of the programmers out there have
> figured out.
>
I often answer emails from home, but I work for NI on the LV development
team. So anything I know about, NI knows about. The info I was
describing about the DLL execution system is not well documented since
we were hoping that it would work we
ll with the way Windows Apps are
typically written. I suspect that we will need to write a Tech Note
to cover the nitty gritty. This sort of info gets lost in manuals,
and it is subject to change as we learn how people are expecting to
use it.
Anyway, my post was to explain why your use of it didn't work.
In general, we believe that LV DLLs are thread savvy, reentrant
VIs can be called from multiple threads simultaneously, execution can
continue in the background after the DLL call has returned, and the UI
is live provided the calling app processes messages in that thread.
If you have other issues or questions, just ask.
Greg McKaskle

When I run this VI "Waveform Time to Date Time String" in LabView 7.0 it will not pass decimals of seconds.

When I run this VI "Waveform Time to Date Time String" in LabView 7.0 it will not pass decimals of seconds. From decimals of inputline. If i disconnect the input to the subVI "Get Date/Time string vi" it will work propperly, it also doses if I reconnect it. I use LabViev 7.0.
So the problem i solved, but i dosent understund why it works in this way. Does it indicate other problems which will make my researchprogram unrelaible ?
Attachments:
Waveform_Time_to_Date_Time_String.vi ‏18 KB

Hello.
I checked your vi and it fails as you state.
It runs fine if: 1 Convert number to timestamp OR
2 Wire a constant to want seconds?
In labview 7.1, no problems.
I think is a job for NI engeniers.
Hope it helps
Alipio
"Qod natura non dat, Salmantica non praestat"

LabVIEW: how to route time base to counter source using 6602.

How do I route the 80Mhz internal time base on a 6602 card, to the source of any counter using LabVIEW? I can only see the option for an external time base, and drop down from source only allows me to select source pins or RTSI lines? I am using the DAQ Assistant!!Message Edited by ddudge12 on 06-08-2005 09:37 AM

ddudge12,
I haven't ever really used DAQ Assistant, but I *think* that the drop-down menu you mentioned is for selecting the Sampling clock, which is different than the counter Source. There doesn't appear to be a way to select a source signal in the DAQ Assistant -- it seems to expect you to wire a signal to the counter's default Source pin.
You'll need to use a DAQmx Channel property node to select the 80 MHz timebase as a source. Attached is a screenshot of a very simple example that will count up as high as a 32-bit int can go, rollover to 0 and continue counting up, etc. It'll take a little less than a minute to rollover if all is working correctly.
-Kevin P.
Attachments:
80MHz Source.gif ‏6 KB

LabView DSC, RSLinx, SLC505 and Data transfer (Best way for large blocks of data?)

I am currently programming in Labview 6.1 with the Datalogging and
Supervisory Control module to transfer 720 floating point numbers to a
SLC505 Allen Bradley PLC (with ethernet) using RSLinx as an OPC server. I
have found that using the Datasocket Write takes about 30 - 40 seconds, and
making the tags and writing to them takes about the same amount of time. Is
it possible to transfer this data faster?
Thanks,
Michael Thomson (Surcher)

Cyril,
I was just experimenting with different ways to transfer the data from the
computer to the PLC. In the past I have built large tag databases with
specific tag names. This made the code rather cumbersome when you wanted to
write to a large group of tags with descriptive names. I was just using
datasocket write as a way to transfer the data to the plc using code to
build the url and without having the DSC engine running. I have found that
importing the tags right from the tag configuration editor with the names
being simply the PLC addresses and then accessing them with the tag write is
considerably faster (under 5 seconds). I can then build the names in an
embedded for/next loop and change them to a tag name before I write to each
one. The appli
cation is a user interface that allows the machine operator
to pick what kind of arch to put on cabinet door part. With the selections
chosen I calculate the servo moves and download the data to the PLC.
Thanks for the link!
Michael Thomson
"Cyril" wrote in message
news:[email protected]..
> Michael,
>
> I am a little bit confused about the configuration here and the
> programming here: why are you using Datasocket Write if you are using
> tags? Are the 720 floating numbers written to 720 different I/O
> Points(registers). If so this shouldn't be that slow especially with
> DSC
> I would strongly encourage you contact the support at National
> Instruments for LabVIEW DSC, either by phone or e-mail and give a
> detailed description of the issue:
> www.ni.com/ask, and communication method phone NI or e-mail NI.

Labview dsc client server

Hi,
I use LV7 and labview dsc.
I would like to read historical traces from a client PC. my database is saved on a server PC. I'm using "Read Traces.vi". It works well but i have to wait 10 or 20 seconds to have results (for only 100 points).
I have no problem for reading tags in real time but it is very too slow for reading historical data.
I would like to know if there is a solution to minimise time for echanging historical data.
Thanks.
Alexis de la fontaine
SECMAI

Hi Alexis,
Are you observing the same delay with Read Traces.vi when you read traces locally? 100 points means 100 I/O points (tags) ?
Remzi A.
Applications Engineering
National Instruments

Labview DSC 8.6

Hi,
i am a new with Labview DSC 8.6, i have an application similar like SCADA development. want to read and store for 300 nos of channels over NI OPC server. but similar application i have done with out using DSC module by using Data socket with OPC server and same data i stored in SQL Data base using database tool kit.
could you send me the user manual for the DSC8.6?
also explain me how we can use to develope the application in best way.
1. The channels are to be configured as programatically
2. data logging with sql data base has to be done by programatically
3. allarms should be logged.
Regards,
Balaji DP

Thanks for the reply.
I figured that they may be different enough not to be compatible with each other, but I was hoping that they could coexist on the same computer, at least the tag monitors on my development computer that doesn't actually run the machines.
Do I have to remove 8.6 DSC to have 7.1 DSC tag monitor work again? 7.1 DSC tag configuration still works. I haven't actually tried to launch the 7.1 DSC engine. I have the 7.1 DSC CDs so I tried to repair it after renaming the shared Tag Monitor directory (so it would reinstall it) but although it installed the DSC 7.1 tag monitor, it didn't work, so there's something else. It didn't reinstall the Citadel database or Logos because it detected higher versions of them.
As far as upgrading the machine computers to 8.x, we will be doing that eventually but its going to take some time so I was hoping to still have a way of monitoring the tags.

LabVIEW DSC 2011 / OPC Client IO Server / Can I write to the OPC Server using OPC Groups?

Hi
I am using LabVIEW DSC module as a OPC client. My Shared Variables are binded to automation system OPC Server via "OPC Client IO Server".
On the OPC Server side it seems that the every write commands comes like one item at time, not like grouped.
Now I have tested this with the NI OPC Server as server and KepServer and LabVIEW DSC IO Server as OPC Clients.
When I use the NI OPC Server : OPC Diagnostics there are different events messages when the update request comes from KepServer or LabVIEW DSC.
There are log files on attachements for both write events.
Attachments:
Data from the KepServer.txt ‏6 KB
Data from the LabVIEW DSC OPC Client.txt ‏18 KB

Hello Pentsi,
I have received confirmation (from the PSE in the US) that DSC doesn't support group writes
There however work-arounds that might provide a solution:
- The first solution I had in mind was like this. Update the 50 OPC items as fast as possible.
Then use a 51st item as synchronization OPC item to check/indicate if new data has arrived/has been set/is available.
So LabVIEW sets 50 OPC values as fast as possible. The 51st value becomes goes from false to true when the first 50 values are written.
When this (51st) value is true on the OPC server you can read out the first 50 values (from the non-LabVIEW side). When you've read out these values, then you can set the 51st value back to false (from the non-LabVIEW side).
In the meanwhile at the LabVIEW side you wait until the 51st value goes back from true to false.
When it becomes false, then you write again those 50 values and afterwards set the 51st synchronization value from false to true.
And this keeps on going...
Note: Keep in mind that you only have to monitor one event at the side of the Automation System OPC Server in this case (the 51st) and based on an event occuring over there you can just do a group read of the 50 others. Also keep in mind that the maximum rate (6500 updates per second) from inside LabVIEW with the DSC Module OPC client I/O server was also mentioned in this document (http://digital.ni.com/public.nsf/allkb/63C043359F1E12538625726E005BCD0C?OpenDocument).
Could this be a possible solution for your problem?
If you're using one of the OPC servers in this list (http://zone.ni.com/devzone/cda/tut/p/id/6417#toc19), then you can also use NI OPC Servers to update tags instead, which supports a faster update rate.
Kind Regards,
Thierry C - Applications Engineering Specialist Northern European Region - National Instruments
CLD, CTA
If someone helped you, let them know. Mark as solved and/or give a kudo.

LabVIEW DSC 2011 / OPC Client IO Server / Write by OPC Group...

Hi
I am using LabVIEW DSC module as a OPC client. My Shared Variables are binded to automation system OPC Server via "OPC Client IO Server".
On the OPC Server side it seems that the every write commands comes like one item at time, not like grouped.
Now I have tested this with the NI OPC Server as server and KepServer and LabVIEW DSC IO Server as OPC Clients.
When I use the NI OPC Server : OPC Diagnostics there are different events messages when the update request comes from KepServer or LabVIEW DSC.
There are log files on attachements for both write events.
Attachments:
Data from the KepServer.txt ‏6 KB
Data from the LabVIEW DSC OPC Client.txt ‏18 KB

Hello Pentsi,
I have received confirmation (from the PSE in the US) that DSC doesn't support group writes
There however work-arounds that might provide a solution:
- The first solution I had in mind was like this. Update the 50 OPC items as fast as possible.
Then use a 51st item as synchronization OPC item to check/indicate if new data has arrived/has been set/is available.
So LabVIEW sets 50 OPC values as fast as possible. The 51st value becomes goes from false to true when the first 50 values are written.
When this (51st) value is true on the OPC server you can read out the first 50 values (from the non-LabVIEW side). When you've read out these values, then you can set the 51st value back to false (from the non-LabVIEW side).
In the meanwhile at the LabVIEW side you wait until the 51st value goes back from true to false.
When it becomes false, then you write again those 50 values and afterwards set the 51st synchronization value from false to true.
And this keeps on going...
Note: Keep in mind that you only have to monitor one event at the side of the Automation System OPC Server in this case (the 51st) and based on an event occuring over there you can just do a group read of the 50 others. Also keep in mind that the maximum rate (6500 updates per second) from inside LabVIEW with the DSC Module OPC client I/O server was also mentioned in this document (http://digital.ni.com/public.nsf/allkb/63C043359F1E12538625726E005BCD0C?OpenDocument).
Could this be a possible solution for your problem?
If you're using one of the OPC servers in this list (http://zone.ni.com/devzone/cda/tut/p/id/6417#toc19), then you can also use NI OPC Servers to update tags instead, which supports a faster update rate.
Kind Regards,
Thierry C - Applications Engineering Specialist Northern European Region - National Instruments
CLD, CTA
If someone helped you, let them know. Mark as solved and/or give a kudo.

Error 1172, an error running a VI in the second time call of the DLL

Hello All,
I am a beginner in labVIEW.
I have to write a test program in labVIEW which uses a DLL created by other programmer.
I called the DLL from my labVIEW to control DIOs, a serial port, communicate with a slave device, perfrom a flashing task.
While testing the program, I found that the program is OK if I use it just once, however, if I want to run it coninuously using a Do-While Loop, it failed with
Error 1172.
As far as I could understand, it seems that the DLL creates a log file in C:\ while it was called for the first time, and the process does not stop taking control of this log file even after the DLL is closed.
Then when the DLL is called for the second time, it looks for the same log file to write new info but as it was taken control by the previous process, there comes an error.
Please find the attached files.
Hope there would be somebody who is able to help me to point out my mistakes in my vi or suggest me a solution for it.
Thanks and Best Regards
Aung
(As the system does not accept the DLL attachment, I changed the extension to .pdf for the DLL File)
Solved!
Go to Solution.
Attachments:
I Basic Flasher.vi ‏60 KB
Failure.xls ‏86 KB

-message deleted -
Message Edited by Ray.R on 11-17-2009 08:01 PM

Unable to do second time MIGO

Dear friends,
I have an issue at mu client's place wrt MIGO.
A PO was created and partial inward of goods has happened.. now for the second time when goods have to be inwarded an ABAP RUNTIME ERROR has occured as below:
Overflow for arithmetical operation (type P) in program "SAPLJ1IEX"
Please provide your valuable inputs and guide me to help resolve .
thanks in advance
nandu

Is this dump seen only for Imports PO? Are you using CVD condition
which are defined as "Fixed amount" rather than "Percentage" conditions?
Please check for the application of the following notes:
1040500 Dump in MIGO and J1IEX for Imports Purchase Order
1125359 Excise duty rate not flowing in J1IEX and MIGO for Import PO
This dump occurs typically for an imports PO, where the BED rate goes
beyond 999%...or runs into infinite decimals. You need to concentrate
on the formula given below, where the value for es_exitem-bedrate should
not exceed 999%...this would typically happen when the BED/CVD value
is higher than the excise base value...
es_exitem-bedrate = ( es_exitem-exbed /
                      es_exitem-exbas ) * 100.
Kindly check in your system if BED value is greater than the excise base
value. Please note that excise base cannot be smaller than the excise
amount/BED value. This will result in dump. here is no solution for this. The only way to avoid the dump is by
nsuring that the base value is always more than BED/CVD value.

LabVIEW DSC: Migration from 6.1 to 8.6 problems

Colleagues,
I need help from someone who experienced with LabVIEW DSC. I would like to recompile pretty old application written in LabVIEW 6.1/DSC 6.1 to LabVIEW 8.6, and got lot of troubles with this.
At the first I have tried to migrate my old scf file as described here: "Migrating from LabVIEW DSC 7.1 to 8.0".
Well, it seems to be OK, and LabVIEW.lvlib library with variables was created, but when I tried to double click on the some items, then exception occurred in LabVIEW (see dsc_exception.png in attachment).
Can you please open test project (attached to this post) and double-click on the Slave005_A0 Item? Is crash happened only by me or by someone else?
The second problem with understanding.
In LabVIEW DSC 6.1 I have used "Read Tag.vi" / "Write Tag.vi" vis for accessing the items. When my VI opened in LabVIEW/DSC 8.6, then these calls replaced with "legacy_Write_Tag_(analog)7x.vi" (see screenshot). I'm unable to found according VIs in DSC 8.6. How can I write/read my tags in the latest version? As far as I can understand, I can use Shared Variables directly. Is this correct? But then how can I read multiple tags? Through DataSocket VIs?
The same with "legacy_Get_Tag_List7x.vi". How can I get items list in DSC 8.6 programmatically?
Or should I leave all legacy* vis in my application?
thanks in advance and best regards,
Andrey.
Attachments:
dsc_exception.png ‏26 KB
dsc_legacy_Write_Tag.png ‏3 KB
TestProject.zip ‏4 KB

Hi Andrey,
Yes, my LabVIEW crashes as well. As you may have noticed, a lot has changed in LabVIEW 8.0 with regards to DSC, the most important being that tags are replaced with Shared Variables. I would recommend that you go through each variable and create them by yourself to ensure the most reliable performance.
If you are interested in reading 'tags', then you just need to drag the Shared Variable and place it on the block diagram (that's the direct way). If you are interested in doing this programatically, then have a look at the DSC Module -> Engine Control -> Variables & I/O Servers -> Get Shared Variable List palette on the block diagram. You can then use DataSocket to access the Shared Variables.
Don't leave the legacy VIs on your block diagram. Upgrade your whole project; shared variables are here to stay. Have a look at the following article to get a thorough understanding of them:
Using the LabVIEW Shared Variable
Let us know if you have more questions.
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies

What are the steps necessary to create an EXE using LabVIEW DSC ?

I´m developing an application in LabVIEW 7.0 using the LabVIEW DSC 7.0 Toolkit. I´d like to know the steps I should take to cretae an EXE for this application.

There is information regarding building a LVDSC .exe at
http://zone.ni.com/devzone/conceptd.nsf/webmain/2f7cf918f3b412db86256a1c006af25f?OpenDocument
It's from the time of LV6, but contains some useful info.
=====================================================
Fading out. " ... J. Arthur Rank on gong."

Second Time Base in LabVIEW DSC 7.0

Similar Messages

Maybe you are looking for