Giseli Ramos

Hi,

Forget the previous message...I've managed the problem. It is just a matter of adding timers, to give time to the DGH to respond before the program finishes.

Thanks,

QUOTE (neBulus @ Jan 29 2009, 04:09 PM)

I just recieved on myself.

Ben

I think that I also received on my inbox...

Hello,

I'm with a strange problem... I'm working with a DGH I/O module (model d1711 - http://www.dghcorp.com/digitalio/) that reads the status of one pair of sensors. When I use Hyperterminal, I can send commands and receive replies from the dgh module via serial port.

But it simply don't work in LabVIEW. When I use even the most simplest code to write to and read from a serial port (using the NI Examples), the dgh module simply don't send a reply to LabVIEW... LabVIEW can write with sucess on the serial port, but don't receive reply from DGH module.

I tried to use the example provided by DGH, but even it does not work (http://www.dghcorp.com/drivers/labview/Dghdemo.vi). I set the correct configuration for the serial port (300 baud, 8-N-1, no flow), but it does not work also.

I'm using LabVIEW 8.6 in Windows, and uses a USB-serial converter (it worked well in another applications using LabVIEW and I think that it is not the cause of the problem).

Anyone have any idea?

Thanks,

When you draw the basic flow of the program, you can take a look on the Data Communication -> Protocols -> Serial (it will appear if you installed NI-VISA, standard for serial comm. in LV). The Smart motors can be controlled by this way. You need to learn how to use the write/read serial port in LabVIEW. It is quite easy.

QUOTE (Scott Carlson @ Sep 2 2008, 08:58 AM)

I definitely don't think you should leave the TCP behind. This sounds more like an OS issue than a Labview issue.

#1 What Flavor of Linux are you using. (I can be more helpful )

#2 My first suspicion is that you have a firewall blocking ports... Have you looked into this?

-Scott

Hi Scott, I'm using Fedora 7... and I'm glad that you remembered me of the firewall issue!

On Linux, it is OK, but in Win, the firewall rules was not correctly applied... Now it is working fine.

Many thanks to all and I learned some useful things in this topic such as the endian problem...

QUOTE (Ton @ Sep 2 2008, 07:53 AM)

Do you have the right port and number? It looks like there is no-listening at that port.

Could you post a screenshot?

Ton

Well, I think that have listening, because my VB program succeeded to establish a communication when I use the example TCP Communicator in the same platform (win X win). The screenshot of the example is here. It doesn't work when is Win X Linux... Strange!

QUOTE (Ton @ Sep 2 2008, 01:20 AM)

The problem is that you can't establish a connection. Strange, what error code is generated on the LabVIEW side?

Ton

When I try to connect to the VB server using LV, it simply don't connect, I get timeout.

Eugen, I tried something with DataSocket, but I'm not satisfied and really want to use TCP things. Don't have any way really?

Philip, thanks for the tip. I will see here if is this problem and will post here the results.

Hi,

I have a compiled program (not mine) in VB which acts as a server that receives commands from my LabVIEW application via TCP port. So, these programs run in differents computers in a local network. They works fine when the two computers are Windows.

If my LabVIEW program runs on Linux, it is not able to establish a communication with the VB program. The cause of the problem maybe that the VB program uses Winsock?

I already tested my connection between a Linux and a Win computer using the examples TCP communicator, so the connection is fine.

Thanks!

QUOTE (marp84 @ May 14 2008, 09:53 PM)

Can you giveme some sample of the methods to tranfer the data, for example i want send the data to other pc through internet or wireless.how i can do that please explain that?

tanx before

LabVIEW have lot of examples in Networking (accessible by clicking in Help -> Find Examples), here you can find useful code to learn how to transfer data between pcs.

QUOTE (Justin Goeres @ May 19 2008, 11:19 AM)

The refnum is like a lifetime ticket to an amusement park. You can come & go (read & write) as you please, but if they close the park down (close the connection) you won't know about it until the next time you visit. Your ticket (refnum) still looks the same as it did before (same address, same promises of happiness, same terrifying mouse character) but trying to visit the park (read & write) causes errors (and disappointment).

What's more, it may be necessary to inspect the error information ("You are not allowed to enter the park because...") at a deeper level to determine why the error occurred (too many people in the park right now / you are not the right ticket holder / the park is closed forever / etc.).

Is that a tortured enough analogy?

Whoa! That were a nice explanation! I understood it better... Thanks! Now I'm looking now for alternative (and right) ways to monitor a TCP connection.

I think that writing in time to time and see if occurs any errors is a reliable way. What do you think?

QUOTE (ned @ May 19 2008, 09:03 AM)

You cannot use that function that way. Instead you need to check the error output from TCP Read or TCP Write. You will probably need to filter the errors, because some errors do not indicate a dropped connection (for example, TCP Read may return a timeout error because no data available, but the connection is still valid).

Well, so you say that I write/read to a tcp connection in time to time...

May be a dumb question, but for which specific things the "Not a Refnum" is made? Only to know when don't use it.

Anyway, thanks for the feedback, ned.

Hello folks,

I have a VI that monitors a TCP connection using the function "Not a Number/Path/Refnum". When the peer (the other side which this VI is connected is a win program in Visual Basic) closes the connection, my VI seems unable to detect the closed connection, it is "thinking" that

the TCP refnum is still valid.

How I can handle it?

Thanks!

Very interesting...... but I'm afraid to see it at night on backyard at home.

I agree with you, about the control version. I will implement it NOW! I was thinking about it, but, at the beginning, the project was small, and after, growed a few... I don't have excuses to don't implement it now.

Aristos, well, I think that your explanations about the conditions to lose a block diagram makes sense. Because I was with some VIs opened, and appeared that message to revert. Duh, I was dumb and clicked on "no".

I have a backup copy, so, no great pain to recreate it, hopefully. But good to know that NI can help if the things really goes hard!

It was important to learn that have much ways to lose VIs....

Many thanks!

PS: Sorry for my english...

I was afraid of this... but hopefully I have a backup copy here (it is a older version, but to recreate the new things....). I'm recreating and for now, I will backup every day.

Well, I really like to know where the block diagram has gone, but okay, let's go to recreate it

Many thanks for the feedback!

QUOTE (crelf @ Apr 8 2008, 02:19 PM)

Show us your code.

I would like to show the code, but what to do if only the front panel appears? Well, anyway, I'm sending below the file VI. Don't mind if LabVIEW asks for subVIs (I would like to send the subvis, but I cannot and is not important for now).

I also tried to unblock programatically, using the method Lock State: Set, setting to Unblocked, but don't works too

Hello folks,

I'm quite anxious here, because a strange thing happened here. I was working on my VI and closed, so appeared a message asking if I want to save. I clicked on OK and a message with the button "revert appeared". So I cancelled the Save, to close the VI.

When I reopened this VI, it is blocked! I cannot see anymore my block diagram! The funny thing is that I did not clicked on VI Properties -> Protection -> Locked (no password). When I try to unblock here, the dialog is disabled, so I can't click on Unblocked!

What I do? And any ideas of the cause of this "mysterious" blocking?

QUOTE(tcplomp @ Nov 29 2007, 05:19 AM)

What you forget is that the image you overlay need absolute coordinates (in pixels), I modified the code to do the following:

http://lavag.org/old_files/monthly_11_2007/post-2399-1196320734.png' target="_blank">

Good luck,

Ton

Ton,

Really, I forgot it. I will do it so.

Many thanks for the reply!

Hi people,

I've made a VI that, in theory, would select an area of an intensity graphic, but it is not working. To catch the area, I created two mouse events, one event with the mouse down on the panel of the intensity graph, and a drop event, when the user finishes the drag and drop.

In the event "mouse down" I catch the coordinates, and put in a cluster of the drag data. In the "drop" event I catch the final coordinates (and convert these coordinates to XY coordinates, same thing to the previous coordinates) and send it to the draw rectangle function.

The VI sounds correct to me, but obviously I'm missing something. Anyone can take a look on my VI and help me?

Thanks!

Many thanks!

Okay, I understand the example for one dimension, now, I'm trying for an array of two dimensions. Let's see if it will go...

Cheers,

It is possible to use the function MgErr NumericArrayResize in a Library Node? I don't want to use CIN...

Rolf, thanks for the hint! I will study it.

QUOTE(silmaril @ Oct 30 2007, 07:27 AM)

It's often difficult to get the return data from a DLL that allocates it's own memory. LabVIEW is much easier to use, as long as it can do the memory allocation.

There is a very usefull function inside Windows kernel32.dll:

void RtlMoveMemory(void *dest, int32_t Source, int32_t length);

You could use this to copy the data from the returned address into an array you allocated in your LV app.

It works fine for me with my own cluster connected to the *dest input using "Adapt to Type" and "Handles by Value".

It should do the same if you have an array instead.

If you have access to the DLL source code, I would recommend following Tomi's advice and change the way you return the data.

I find it easiest if the DLL gets a pointer to the memory that is already allocated by LV.

Thanks for the answer!

Tomi, yes, I release the array from LV to the shared lib. Also have the source code, so I can change it.

Well, silmaril, I'm using LabVIEW for Linux, so, there is no way to use the function inside Windows...

Okay, if is better to the shared library get a pointer to a data allocated by LabVIEW, how could I send this pointer? As you said, after the creation of the array in LV, I use a cast to a type to get the pointer for this array? I'm sorry, but I don't understood well this point.

Cheers,

Hi everyone.

I'm using a shared libray where it creates a array and return a pointer to this array. I would like to know how, within LabVIEW, I can access the data from this pointer.... Someone can help me? Here is the code of the C shared libray:

int *pointer(void) {
	int *array;
	array = malloc(sizeof(int) * 5);
	array[0] = 0;
	array[1] = 1;
	array[2] = 2;
	array[3] = 3;
	array[4] = 4;
	return array;
}

Thanks!

QUOTE(neB @ Oct 16 2007, 04:30 PM)

Welcome to LAVA Giseli!

We have a lot of physics types around here. What is the nature of your "Astonomic project"?

How are you planning to use LabVIEW?

Ben

Hi neB!

Well, this project is to build a Fabry-Perot instrument to be deployed on the SOAR telescope. Where the LabVIEW fits, is on the system control of this instrument. The people of SOAR generally uses LabVIEW for the control of the telescope and it is usually a "standard" for the control of instruments too.

That is it!

Hi everyone,

I am new at this forum, and I'm impressed with the expertise of this forum. Because of this, I wanted to create an account to share and learn with these people.

I started with LabVIEW at the beginning of 2007, working on a astronomic instrument project. Astronomic projects are huge... but is a nice challenge!

Hope to be of some help!