Timer in a Thread

[bakero]

Hi guys!

I have a routine which is controlled by a timer. It works perfectly.

The problem is that now, I need to run this routine several times, so I need to start differents threads so that my program doesn't get hung up.

I've been trying to start my timer inside a thread, but it doesn't work!!

Any idea what's going on??

I'd be pleased of hearing your advices.

Many thanks in advance.

Regards

[Joacim Andersson]

You probably don't want to create different timers in different threads but rather create a thread in the Timer_Tick event that will run the code.

[Grimfort]

Or just change the timer type from a forms.timer to a timer.timer which does not use the main thread.

[bakero]

Thank you both.

I'll try it and I'll let you know how it works

See you soon!

[dbasnett]

@OP - without a better description of "I have a routine which is controlled by a timer." it is difficult to give a good answer.

[bakero]

@OP - without a better description of "I have a routine which is controlled by a timer." it is difficult to give a good answer.

Wow! I'll do my best now

My routine reads RFID data from my serial port. I have to read continously, and the reader needs a request command not only each time I want to read but also when a tag is within its range. If I send the the request command but there is nothing within the range, I'll get nothing (obviously) and the same happens if a tag is within the range but there is no command. So I need command and tag at the very same time

So for that reason, the best way to do it is with a timer with is continously sending the command, until a tag is detected. At that momment, I stop the timer.

Now, I need to add more readers to my application, so I'll use threads in order to control those timers. And here is where the problem comes.

I hope it is now clear enough.

I am sorry for my previous message.

Regards.

[MaximilianMayrhofer]

One question, why are you polling when you can use the DataReceived event of the listener class?

Other than that, if polling for some reason turns out to be absolutely necessary, then you would definitely use System.Timers.Timer, as the tick event is raised on a separate thread which does not impact the UI. The caveat to this is that when you do want to invoke changes to the UI, like a label update, you'll have to use delegates.

[dbasnett]

One question, why are you polling when you can use the DataReceived event of the listener class?

Other than that, if polling for some reason turns out to be absolutely necessary, then you would definitely use System.Timers.Timer, as the tick event is raised on a separate thread which does not impact the UI. The caveat to this is that when you do want to invoke changes to the UI, like a label update, you'll have to use delegates.

I sort of agree. If each RFID reader needs a command to transmit then one timer should be all that is required. My guess, as is Max's, is that you are not using the DataReceived event handlers for the serial port to read the data.

[bakero]

I am already using the DataReceived event, but maybe not in the right way regarding your comments...

The point is that I can't tell the reader 'Read' and then it keeps reading in a sort of background...The 'Read' command must be sended when a tag is within the reader range. Otherwise I must re-send it untill the tag can be read by the reader.

That's why I need to do that kind of loop with the timer.

[dbasnett]

I am already using the DataReceived event, but maybe not in the right way regarding your comments...

The point is that I can't tell the reader 'Read' and then it keeps reading in a sort of background...The 'Read' command must be sended when a tag is within the reader range. Otherwise I must re-send it untill the tag can be read by the reader.

That's why I need to do that kind of loop with the timer.

How do you know if there is a tag within range?

[Shaggy Hiker]

He has to poll for the presence of a tag.

The whole thing is kind of awkward, which makes me think that there might be a better design. The RFID reader I deal with HAS a better design, so I don't have to deal with all the garbage you are going through, but that's life.

My question is whether or not you will have multiple hardware readers? In my case, two RFIDs within the field will interfere with each other and neither will be seen. How is it that you can have multiple reads?

I am thinking of a design closer to a TCP server, where one thread is doing the reading, then when something is seen, it spawns a new thread to handle that item and passes off to that new thread. I'm not sure that such a thing is possible in your case, because I am not familiar with an RFID reader that would allow for multiple reads, nor do I know whether or not there is any further work to do.

[dbasnett]

He has to poll for the presence of a tag.

The whole thing is kind of awkward, which makes me think that there might be a better design. The RFID reader I deal with HAS a better design, so I don't have to deal with all the garbage you are going through, but that's life.

My question is whether or not you will have multiple hardware readers? In my case, two RFIDs within the field will interfere with each other and neither will be seen. How is it that you can have multiple reads?

I am thinking of a design closer to a TCP server, where one thread is doing the reading, then when something is seen, it spawns a new thread to handle that item and passes off to that new thread. I'm not sure that such a thing is possible in your case, because I am not familiar with an RFID reader that would allow for multiple reads, nor do I know whether or not there is any further work to do.

I did not want to assume that.

If that is correct then the timer should be sending the poll frequently enough that it doesn't miss anything. If there is a tag in view the response should trigger the handler.

[bakero]

How do you know if there is a tag within range?

I don't know. That's why I have to read all the time. Otherwise, I'd only send the read command when I know there is a tag.

Actually, the command sequence is

Pc --> Reader: 'Read'
'Any tag?'

Reader --> PC: Yes / No
If 'Yes', I read the tag ID

I know that this is a problem with the readers way of work, but I can't change it.

@Shaggy: I have 8 RFID readers. They are all controlled by the same PC, but they are far enough to avoid interference. I'm thinking in a desing like your suggestion, but the problem is how to start the timer in the thread doing the main reading.

The other thing, much easier, is to use several photocells, so I can know when there is a tag within the range and then start reading the ID.

[Shaggy Hiker]

What you are doing now is safer, though more computationally burdensome, than the photocell idea. After all, your current system will either work or fail. Once you add the photocells, you now have two systems that can fail, either of which will result in the tag not reading. Far easier to fool a photocell than a reader. On the other hand, it will reduce the need.

After hearing your description, I don't think you can really get around polling. I see only two ways to do it, one of which is what you are already thinking about: Have one thread per reader. However, you don't actually have to have multiple timers. You could have one timer, and whenever it ticks, read all the readers. This has a problem, though, in that the computer will be really busy whenever the timer ticks, and will be idle between ticks. A better solution would be to have a timer running at 1/8 the interval you think you need for reading. Whenever it ticks, poll one reader, then next time poll the next reader, and so forth. This will be much more efficient as long as you are willing to wait at least about half a second between polls. Any faster than that and you will probably be exceeding the resolution of the timer.

Using multiple threads would not actually be necessary in the previous scenario. If you have to get your read speed greater than one read every half second, then you would need multiple threads, but you still wouldn't really need more than one timer. Whenever the timer ticked, you'd spawn eight threads. Each thread would poll one machine, and if it saw an RFID, it would read it. Whether those threads would be more efficient than using a single thread is hard to say. The polling and reading steps seem too fast to really benefit from threading.

Technically, you could use multiple timers, but you would only really gain if you could keep the timers out of synch so that not too many timers ticked at the same time.

[Grimfort]

I have a similar setup when reading stats from remote machine. In my case things are a little more complicated by the fact that my actions may take 100ms to get a response, or 30 seconds due to timeout. In all my tests I used a single timer to check an action queue of items to run. Each item would be checked for next action time (like 30 seconds polling) and when ready would fire off on a new thread. I could have 1000 different things to check each with different polling intervals. Anyway, in all my tests I found it no burden at all to run 10 threads at any one time, using the timer every 1/2 second to add a new one if any had finished. I pushed it up to 20 threads and it added a little more CPU bursts on a client desktop. On the server (8 core x 3gig!) it had no problems running 50.

So my point is 8 threads should cause you no issues. Create a collection of classes, 1 for each device, and using a timer check if its time to poll the device. If so mark it as busy, using a thread from the threadpool launch the test, when the thread completes unmark it back ready for the next timer tick. If your device takes longer then the x ms in test (ie due to it finding a tag and needing to read), it will be picked up next time.

[dbasnett]

I don't know. That's why I have to read all the time. Otherwise, I'd only send the read command when I know there is a tag.

Actually, the command sequence is

Pc --> Reader: 'Read'
'Any tag?'

Reader --> PC: Yes / No
If 'Yes', I read the tag ID

I know that this is a problem with the readers way of work, but I can't change it.
...

Let me see if I understand.

1. PC sends a Any tag question to the reader.
2. Reader responds yes or no.
3. If yes, PC sends read request to read the tag.
4. Wait some period of time and go to step 1

Does the reader respond immediately with the yes / no?

What sort of speed do the items to be read come into distance? How often?

I know a little about serial ports, and my opinion is that you should use the DataReceived event handler for each port.

[bakero]

Let me see if I understand.

1. PC sends a Any tag question to the reader.
2. Reader responds yes or no.
3. If yes, PC sends read request to read the tag.
4. Wait some period of time and go to step 1

Does the reader respond immediately with the yes / no?

What sort of speed do the items to be read come into distance? How often?

I know a little about serial ports, and my opinion is that you should use the DataReceived event handler for each port.

Yes, that's right.

I am not using the application in a conveyor belt but to identify animals, so it's not a very high speed when I have to read each reader.

Maybe with one timer will be enough. I have to think about it, because I will have to change my first design and I don't now how long this is going to take me...

I guess you've all realized I am not a VB.net expert...

[Shaggy Hiker]

Are you reading PIT tags? If so, what reader are you using? If not, what type of animal are you tagging?

[dbasnett]

Yes, that's right.

I am not using the application in a conveyor belt but to identify animals, so it's not a very high speed when I have to read each reader.

Maybe with one timer will be enough. I have to think about it, because I will have to change my first design and I don't now how long this is going to take me...

I guess you've all realized I am not a VB.net expert...

You didn't answer whether the reader responds immediately with the yes / no?