Hello,

status 0 mean no errors on exact moment of read that status value. I recommend to you check NDR output status, if it will be true, you have bytes received. Then you can also check LENGTH, how much bytes you have inside receive buffer. Look, important is, how you've defined your receive buffer structure, this info can be also helpful. Post screenshot of your piece of code where you have RCV or also what you decide to be for show to us.

Ok,

I expect because you have your both devices under your control (also that Atmega controller), you can make simple test. Prepare simple condition that after NDR->true set EN_R to false. Don't forget before check with other code that received LENGTH value. Simply that EN_R define like TAG and prepare watch table with your needed TAGs to see their values. So first enable RCV EN_R via Watch table, then send from Atmega message. Your code automatically check NDR (message received), reset EN_R and you can check your LENGTH for sure. You simply need test functionality of cyclicall receiving to same 0-th offset in buffer. After check you can again set manually EN_R and send from Atmega again.

Hello

I don't have access to the hardware at the moment but the screen shoot with RCV block is attached. Actually there is only this one, it was simple program for testing.

Data should be placed inside "ID_numery" data block. There is "Ibutton_numer" data type consisting of 20 bytes of data.

I willl try to follow your sugestion tomorrow.

Regards

Hello,

DB looks to me ok also enough place for receive frame, but 2 sugestions.

1. don't use physical input for execution of RCV in this case, use some memory bit, of course not used anywhere in code (standard recommendation). Simply in case of not use steady signal, your EN_R can oscilate from 1 to 0 in any cases, therefore use memory bit. Also my previous post recommendations can't simply work with this solution.

2. is reason using RST instruction? I see it probably used on one Picture. Don't use it, disable it for now tests. Also never used this instruction in my history, simply didn't have reason to.

Give then results of test.

Update: simple simulator option, if you have no device available run that Hyperterminal and simulate your Atmega

Hello,
I made some tests, according to your advices. I have removed physical contact and RST block.

I have used memory bit for triging the receive procedure.

1) Data from cell 4 to 10 were changing, rest was always this same - I used two keys with different numbers.
2) LENGHT value is changing, depends what I declared in DB - is it not strange?

I will try to connect computer with Hyperterminal to PLC today.

Could it be some hardware mismatch?

Any ideas?

hello,

pls post again clear info what Atmega sends with some example, this isn't clear to me now. I expect when there isn't some button pushed, no data can be send from Atmega, or Atmega sens cyclically data, this situations explain pls clearly. Probably from this situation all depends. Did you that reset EN_R after NDR->true? Show in pdf code with RCV again, also that length pls as DEC value in watch table, better can be read and not need convert...

Update: what option did you set in CP cfg as receive condition?

Hello,

ok, what exactly controller is, Arduino? Ok, again pls, without exactly know what exact messages sends mc (also how frequently), we can't help you. Also you didn't answer what condition you did set as end of frame condition in CP. For standard cases you can use 4ms character condition as end of frame, then NDR will work also with this condition. This looks like in my opinion, that mc sends 2 bytes with 2 bytes at end as mark of end of message. Also mc maybe sends one byte per time continously and you must detect this, also collect complete frame internally. Give us info about exact system how mc sends messages.