Port Locked Errors

[mse3000]

Not sure if this is in quite in the right section but here goes.

I am having a few issues with port locked errors.

There doesn't seem to be any regular time intervals between the errors and they are not accompanied by any timeouts. So I am wondering, is it possible that due to the number of sequences I am running, are the outputs from the sequences clashing with the data requests around the system? If this could be the case is there any way to tell DF to prioritise the inbound and outbound traffic to avoid this from happening? I have copied a sample of the errors with time stamps below.

12/14/10 13:46:55.071

P-ModbusRTU 0013: Port locked

12/14/10 13:51:07.428

P-ModbusRTU 0013: Port locked

12/14/10 13:52:03.272

P-ModbusRTU 0013: Port locked

12/14/10 13:57:52.768

P-ModbusRTU 0013: Port locked

12/14/10 13:59:28.578

P-ModbusRTU 0013: Port locked

Many thanks,

Regards,

Mark

[AzeoTech]

There isn't a way to prioritize, other than adjusting sequence priorities. The best solution is to look at your comms and see if there are large blocks of time used in comms. For example, if you had a bunch of channels all at Timing = 1 that required, say 10 modbus queries, and each query required 100ms, then to read the entire block of channels would require the entire second and there would be no room left for any other comms. In this case you'd have to increase the Timing.

But lets say you increase the Timing to 2, so now only 1 second out of 2 is used. Now there is some space, but there is still this block 1 second long when outputs can't occur because the port is locked up doing input comms. So, in this case, you'd want to split your 10 queries up so there were breaks. So, for example, you could put half on Timing = 2, Offset = 0, and half on Timing = 2, Offset = 1, or better yet split into four. Just make sure and keep consecutive modbus addresses of the same I/O type and D# together as DAQFactory will automatically query them in a single call.

[mse3000]

OK so are you saying that DF is unable to check the status of the port before trying to send outgoing messages resulting from whatever may be in a sequence. If this is the case surely using an offset would make no difference as the time taken to query all devices is the same whether it is split into four sections for example or left as one data block.

I was under the impression outgoing data was tagged on to the end of the incoming data stream, hence avoiding locking the port. And as long as the timing was great enough this would not be a problem. If I need to use offsets, is there a timeout that DF uses before trying to send the outgoing data regardless of the port status and is this a value I need my incoming blocks of data to be lower than in order to avoid this problem. i.e. 1000 ms?

Regards,

Mark

[AzeoTech]

Actually, DAQFactory does check the status of the port before trying to send outputs, that's what a locked port is. It will actually wait, up to the timeout value on the port, for the port to become unlocked before it will give up and throw a port locked error. The problem is that its done in a multithreaded environment and Windows controls the thread switching. So, if you are reading, say, 10 input blocks, and that takes 1.5 seconds, its likely that Windows won't thread switch to your output command during the microsecond between input block reads when the port is unlocked. Instead, the output largely has to wait until all 10 input blocks are done, and since that takes 1.5 seconds, and presuming your timout is still 1 second, its likely that it will timeout waiting for the port to be released and you'll get a port locked error.

By using offset, you are taking 1 block of 1.5 seconds with, say a 0.5 second gap at the end (assuming 2 second loop time), and making, say, 2 blocks of 0.75 seconds with two 0.25 seconds gaps, or better yet, 4 blocks of 0.375 seconds with four 0.125 second gaps. 0.125 seconds is more than enough time for Windows to thread switch into the output and actually perform that command before coming back to the next input block.

Make sense?

We are considering options to make this problem easier, most likely with single threaded queue similar to what you describe, but that requires some architecture changes and we'd need to consider whether that will cause other issues, most likely from the fact that sequences and all are multithreaded.

[mse3000]

That makes almost perfect sense! I am not a computer tech so talk of single and multi threading in windows does lose me a bit, but now the port timeout setting finally has meaning. I had become so engrossed with timing and offsets I completely forgot to even consider the timeout.

Could you just confirm one thing for me though to get everything sorted in my head. If I had two blocks of data taking 0.75s each on a 2 second timing. If the output data time exceeded 0.25s in length would this then cause other problems, or would the overall timing just be increased by the time needed to send the extra data. I.e. if the outgoing data took 0.5s to send in a gap of only 0.25s. Would the overall timing effectively become say 2.25s based on one set of outgoing data, or would it remain at 2 seconds with some data failing to be sent/recieved?

Many thanks for the replys, I think I should be able to finish off one of the larger systems now once and for all!

Regards,

Mark

[AzeoTech]

The timing would remain at 2 seconds. This is actually a problem point if you don't leave enough space. DAQFactory will attempt to catch up when it falls behind, and so there won't be any space for more outputs if it does fall behind, until it catches back up.