Ltc

Niccol?

Hello AMX World!

I have an machine AV-TC 60 RLV alpermann+velte that LTC reads and it converts in hex code.

the NI3100 does not see the data in RX, while if I connect AV-TC 60 RLV at PC I can read the strings.

can you help me?
bye

Chip Moody

Niccolo, have you set up a buffer for incoming data in your program?

The following things should be in your code:

DEFINE_VAR

VOLATILE CHAR MyDevBuf[255]  // Change the size as needed for the amount of data that comes in from your device

DEFINE_START

CREATE_BUFFER MyDev, MyDevBuf  // MyDev being the device name associated with the appropriate RS232 port

DEFINE_EVENT

DATA_EVENT [MyDev]
{
  ONLINE:
  {
    SEND_COMMAND MyDev,'SET BAUD 9600,N,8,1'
    SEND_COMMAND MyDev,'HSOFF'
    // Adjust these to match the needs of your device
  }
  STRING:
  {
    // code here will be triggered EACH TIME new data comes in the RS232 port
    // you should run a routine here that examines MyDevBuf for data you need
    // and removes said data
  }
}

Without the CREATE_BUFFER declaration, you will not see the RX light turn on even if data is coming in your port. Also verify that TX and RX lines from your device are wired correctly.

- Chip

tom goez

Ltc

Respectfully, the CREATE_BUFFER routine has nothing to do with the RX light working or not. I haven't used a CREATE_BUFFER since NetLinx came along. I would code it:



DEFINE_VAR

MyDevStr[255] // Change the size as needed for the amount of data that comes in from your device

DEFINE_START

DEFINE_EVENT

DATA_EVENT [MyDev]
{
ONLINE:
{
SEND_COMMAND MyDev,'SET BAUD 9600,N,8,1'
// Adjust this to match the needs of your device
}
STRING:
{

MyDefStr = ' ' //clear the string every time data comes in
MyDefStr = data.text

// code here will be triggered EACH TIME new data comes in the RS232 port
// you should run a routine here that examines MyDevStr for data you need
// and parse what you need out of the string
}
}

Danny Campbell

My understanding is that a Create_buffer, String section in a Data_Event, or a specific Send_command in the Online section of a data_event, (SEND_COMMAND dvDEV,'RXON') will cause the RXON to be issued. In other words, I think that both Tom and Chip are correct.

tom goez

Ltc

Danny you are correct, too.

Prior to the NI-2000 series, the RX light would work no matter, as long as the baud was set to 9600 baud, without any intervention. I neglected to put that in my response, so it's an incorrect statement on my part because the CREATE_BUFFER does initiate the 'RXON'.

I understand that around that time the NI-2000 series came out, AMX turned 'RXOFF' on new units to keep strings from flooding the masters and UART buffers unknowingly.

Crazy, how things change!

Hedberg

tom goez wrote:

Respectfully, the CREATE_BUFFER routine has nothing to do with the RX light working or not. I haven't used a CREATE_BUFFER since NetLinx came along. I would code it:
[...]

It seems likely to me that the OP's problem may be due to the master starting up in receive off. It's a common enough occurrence and it seems to pop up here about every month or so. I even discover it for myself about once a year, but that may be a specific gravity problem.

Eliminating the create_buffer stuff seems cleaner, and it's what I do also, but some folks have discovered that the buffer for data.text may not always be big enough. I think the situation involved processing a large amount of information from a website and overflowing the buffer. Probably a rare problem, but it is a time where the create_buffer would work and the data event string handler would not.

Hedberg

tom goez wrote:

STRING:
{

MyDefStr = ' ' //clear the string every time data comes in
MyDefStr = data.text

// code here will be triggered EACH TIME new data comes in the RS232 port
// you should run a routine here that examines MyDevStr for data you need
// and parse what you need out of the string
}
}

It doesn't happen very often and I can't recall the equipment (it may have been a little IP to RS232 box), but occasionally, data.text will hold either more or less than a complete serial transmission. Technote 616 discusses this and there have been some nice solutions posted to the forums as well.

Niccol?

thanks amx world!

for help me, therefore effective and fast.

bye

AMXJeff

Create_buffer

Hedberg is correct, you cannot trust the data.text will have a complete message from a serial device. Serial depending on the baud rate sends 8 bits at a time. The string event may trigger multiple times before the complete message has been received. DATA.TEXT gets cleared each time the STRING event is called. Example 1 is one solution, but concatenation we have found, takes more processor time then actually using CREATE_BUFFER. Example 2 uses a CREATE_BUFFER statement. STRING events also cause the RXON command to be sent. So Chip's method is prefered.

Example 1:

DEFINE_VARIABLE

VOLATILE CHAR cBuffer[100];
(***********************************************************)
(*                THE EVENTS GO BELOW                *)
(***********************************************************)
DEFINE_EVENT

DATA_EVENT[dvRS232]
{
	STRING:
	{		
		cBuffer = "cBuffer,DATA.TEXT";
		
		WHILE (FIND_STRING(cBuffer,"$0D",1))
			ParseMessage(cBuffer);
	}
}

Example 2:

VOLATILE CHAR cBuffer[100];

(***********************************************************)
(*                STARTUP CODE GOES BELOW                  *)
(***********************************************************)
DEFINE_START

CREATE_BUFFER dvRS232, cBuffer

(***********************************************************)
(*                THE EVENTS GO BELOW                      *)
(***********************************************************)
DEFINE_EVENT

DATA_EVENT[dvRS232]
{
	STRING:
	{		
		WHILE (FIND_STRING(cBuffer,"$0D",1))
			ParseMessage(cBuffer);
	}
}

Niccol?

thank you,
I apply your metod and now I read correctly the string! I insert an clear_buffer every time I recive a string!

thanks all!

bye or CIAO!