reading .CVS file by Labview online!!

[jftak01]

To LV_Pro:

that's a simple comma format .CVS file.

 I have attached one sample.

[RTSLVU]

One of the features listed for this motor controller is:

RS485 ModBus-RTU Communication Interface for Remote Control by PLC or Other Devices

Why not just read the values directy into LabView via ModBus using an RS-232/RS-485 converter and the MODBUS Library for LabVIEW?

http://sine.ni.com/devzone/cda/epd/p/id/4756

BTW: They don't like it when you start two threads that are basically asking the same question...

---

jftak01 wrote:

it's a great Idea if it works.!!

I just don't know how to analysis its data in Labview!!!  you know... in DriveView software I can see the voltage, current, power and other motor parameters easily ... every thing is readyin Driveview

Is it easy to get motor parameters by your procedure????

Would you please reply your answer on following link: http://forums.ni.com/ni/board/message?board.id=170&message.id=478020#M478020

because i like other guys see your idea , too...

I have uploaded some files and pictures overthere too

thank you so much.

jeff

---

This is exactly why you should not start two threads on the same subject...

Anyway I am no ModBus expert but most commonly values are read from a devices ModBus registers in one block transfer.

They might require some scaling or other decoding, but this information should all be available from the manufacturer.

[GoCougs]

Jeff-

As was mentioned, please keep your question in one location.  I want to stop and clarify what has been said and what needs to be done.  Let me know if any of this information is inaccurate

You have a third party program (Drive View) that takes measurements and writes that data to a Comma Seperated Value (*.csv) file.  You want to be able to access that file from LabVIEW while Drive View is writing to that file and display the data in LabVIEW.

The biggest issue that you are running into is that Drive View opens the CSV file and does not close it until it is done writting to the file.  You will not have permissions to that file while Drive View has it opened.  That means that no other program can access that file during the time Drive View has its hands on it.  

As I see it, you have two choices.  First, you can wait until you know Drive View has closed the file, and then read from it.  Second, you can write a LabVIEW program to emulate what Drive View is doing and not use Drive View at all.  At that point LabVIEW will always have full control of the data and you can display it and write it to a file at the same time.

Message Edited by Scott W on 02-26-2010 11:42 AM

[jftak01]

first of all,I didn't know that application engineers of NI would reply in Forum 

Yeah... that's exactly my problem...

So you mean there is no way!! But if it was possible.. it would be great capability of Labview!

anyway, to emulate DriveView program I have to use Modbus in Labview and i think it would be really hard to get final output such as voltage, power, current, RPM,.. -like diveview-  Using Modbus.

Is this the only possible way?

thanks 

[GoCougs]

Not being able to access a file that another program has opened isn't inherent in LabVIEW.  It's an operating system hinderence, Windows won't allow it for any program.  There's nothing LabVIEW can do about opening a file that Windows has assigned to a different program.  Only that program can be set to release "ownership" of that file.  If there is a way to change Drive View to Open, Write, and then close a file each time, then you might have a chance to read from it at the intervals the program as closed the file.  At that point you would run into timing issues, because if LabVIEW is reading from the file when Drive View wants to write to it, Windows won't allow that either.  Windows does that to protect the integraty of the file, without that "feature" your CSV file could be greatly corrupted.

 LabVIEW absolutely can use MODBUS.  The easiest way is using the DSC module (found here: http://sine.ni.com/nips/cds/view/p/lang/en/nid/1010) or you can get down to the nitty-gritty and do it yourself with the modbus library (found here: http://sine.ni.com/nips/cds/view/p/lang/en/nid/201711).  The code you will need to write should be pretty straightforward.  There are tutorials and examples online that will guide you through how to use either one of these options.

The only possible way to do what you want to do safely (without corrupting your file) is to have LabVIEW be the program that acquires all the data and processes all the data.

[jftak01]

could you please send me some tutorial and sample links?? I'm not familiar with modbus!!

thanks  scott

[LV_Pro]

If you do a search for "modbus" on this forum you will find numerous discussions. I was part of a recent thread where I had a link to a Eurotherm manual, which is directly applicable to your specifc problem, but did have some very useful Modbus information that could be helpful. You will also need to get the manual for your unit, if you don't already have one, that describes that instrument's specific modbus implementation. Modbus is a protocol that describes how data is to be sent and received from an instrument, but how the specific manufacturer implements their own hardware, what addresses are for what values, etc., is entirely up to them. Look around a bit on the web, for your equipment's manuals. Give it a try, come back with your results and "we" will see how we can help. It is a moderate task, but is the best way. Unfortunately, as the previous posters showed, your program (or more accurately Windows) won't allow others to read it while it is using. My thought that it might be possible was from some programs, Word for instance, allow a copy to be opened for reading while the original was open for editing elsewhere. It was a long shot.

[GoCougs]

Jeff-

If you don't have any experience with modbus, then there will be a fairly steep learning curve.  You can find an example here (http://zone.ni.com/devzone/cda/epd/p/id/6153 ), but essentially it is a protocol that your devices use.  You should read up on it to see if this is something worth looking into (http://zone.ni.com/devzone/cda/tut/p/id/7675 and http://en.wikipedia.org/wiki/Modbus) for your project.

You could always look into using LabVIEW purely as a post processing application that does the processing you need on the data after it's been acquired and Drive View has closed the file.

[rolfk]

---

Scott W wrote:

Not being able to access a file that another program has opened isn't inherent in LabVIEW.  It's an operating system hinderence, Windows won't allow it for any program.  There's nothing LabVIEW can do about opening a file that Windows has assigned to a different program.  Only that program can be set to release "ownership" of that file.

---

While this information is in principle right, an application has the choice to open a file for reading and/or writing and at the same time also define if other applications are allowed to read, write or do nothing to it. Obviously DriveVIEW seems to like to lock out other applcations instructing Windows not to allow any other applciation to open it while it has it open. There is nothing LabVIEW could do about that. One last check would be to try to open the file explicitedly for read only in LabVIEW. Even if DriveVIEW would allow read access, trying to open the file in LabVIEW for read and write would still fail with the same error. But by limiting to read only access it might work.

The Open/Create/Replace function by default tries to open a file for both read and write access. In order to only open a file for read access you should provide the read-only value to its access input.