Two Com Problem

[raining010]

Hi Admin

 

I met new issue, I configured two devices using two com ports in the computer. I connect one com5 to device, disconnect the other com4 port to the device.

Did comm monitor, it keeps sending request to com4, and didn't send anything to com5. If I delete the comm device which at the same time delete com4, then it's ok, it starts to send request to com5.

 

Think it should not be like this. It could work with other com port disconnected.

[AzeoTech]

I'm not exactly sure what you are doing.  But I will say this: the name of the comm port in DAQFactory does not mean anything.  Only the comm port number specified matters.  Also, deleting the comm device doesn't delete the comm port.

[raining010]

Hi, I made a mistake, 

I deleted COMM device at menu/quick, which didn't delete relative com port, it only deleted the device.

To delete com port, should enter menu/device configuration/select/delete. This will only delete the com port, not device

 

But the situation is as this, program has two com ports linked with 2 external devices for communication. I found, if one com fails to talk with outside; the other com will not send the request, because I use comm monitor, no text there

[AzeoTech]

What release of DAQFactory, and can you post or email your .ctl document so I can check your settings.

[raining010]

Hi, Admin

I have sent you program - question Two Com Problem - forum - raining010.

I use DF pro 5.87a

Thanks

[AzeoTech]

Thanks.  That helps.  The problem is that all your channels for both devices have the same timing and offset.  This means they all run in the same thread and DAQFactory will read all the channels in one device, then all the channels in the other.  If one device starts timing out, the system won't get around to the other device until its done cycling through all the timeouts.

 

The solution is simply: take all your channels for the second device and give them an offset of 0.5, or even 0.01.  It doesn't actually matter as long as its different than the first device.

 

Please note: this only applies because you have two devices on two different serial ports.  If both your devices were on the same serial port in a RS485 multidrop arrangement, then the serial port itself would force you to do everything sequentially and you would want the same timing and offset.  Since you are on different ports, you can take advantage of DAQFactory's multithreading and read both devices concurrently by adjusting the offset.

[raining010]

Thanks for your quick teaching. Understand it now, I read this in other topics, but didn't aware at that time.

[raining010]

Hi, Mr Guru

 

I used your way to solve two COM conflict issue. Now with channel number increasing, the DF runtime's response is becoming slower and slower. Now it costs CPU load 20%, I found while it exceeded 23%, the DF runtime is hard to have response to operation and display.

 

I removed nearly all V channels into test channels, and some other global variables.

The channels I use can be sorted to 3 types. One is first COM reading channels, two is the second COM reading channels, the last type is test channels used for saving bits.

 

Although there are many sequences, but most of them don't run. I only have 7-10 sequences. These should not be reason.

 

I haven't written codes for packing bits yet, it's my next step.

And I need to define 60 more test channels to saving bits as alarm variables, I defined them before, but CPU went to 23%, DF had difficult response, so I had to delete them.

 

I tried to set offset as 0.2. 0.4, 0.7, etc for every 200 channels, but found it became worse.

 

I'm sending my program to your mail box, in case you might need to check. If you have time, please have a look, thanks for your help

[AzeoTech]

What sequences are running?

 

Also, are you sure you can't access all these discrete inputs and outputs using Coils and Input Status instead of a packed holding register?

[raining010]

Hi, nearly no sequence is running.

I think the main load is in channel inputs and channel events, I wrote many unpacking codes inside channel events.

 

"Also, are you sure you can't access all these discrete inputs and outputs using Coils and Input Status instead of a packed holding register?"

To be honest, I'm not very sure. And I don't know how to access bit inside DF, in Citect, I just input 40001.5. In DF, how can I do? In remote device, I only know the 5 bit of 40001 is the running state. And 40002.2 is the start command, for example. Should I use read coil status and force coil? (I will test today first)

[raining010]

These I/O types need positive integer, can't input 40001.5

[AzeoTech]

Citect must have a built in unpacking mechanism. 40001 is a holding register.  However, many PLC's will also put registers in multiple places.  Its possible that 40001.5 is also coil # 5 (or 4 or 6 depending on the numbering scheme) and 40002 is #18 (or 17 or 19).  If its safe, you might try creating a coil register (for outputs) and try changing them or see what happens.  If it works, you'll find it MUCH easier to deal with.  If it doesn't, a better solution might be to use the 40001.5 notation in DAQFactory as well.  Its a nice way of doing it, will run much more efficiently for you, and now that we have it so you can put strings in for channels, something that we can pretty easily implement for you.

 

One reason why it might be running slow is, as you said, the channel events.  It appears the channel events often then change another channel (or 16) and that of course trigger's those channels events.  The problem is that the alarm checking gets triggered with each channel update triggered this way cascading the checking and bogging things down.  You might want to consider manually triggering alarm checking instead.  Its simple.  First, set Alarm.Paused to 1 to stop automatic checking:

 

Alarm.Paused = 1

 

Do that in a startup sequence.  Then have another sequence that loops every second and checks the alarms:

 

while(1)

   try

      alarm.checkAlarms()

   catch()

   endcatch

   delay(1)

endwhile

 

The problem with this method is two fold:

1) it's possible it will check alarms in the middle of acquisition.  So, if you have an alarm that, for example, requires both x and y to be 1, and the checking occurs after x has been read, but before y, it might not trigger until the next go around.

2) likewise, if the alarm checking is much slower than the acquisition, its possible to miss a short event.  So, if x goes to 1, and then returns to 0 before the checking occurs, it will be missed.

 

These can be avoided by triggering your reads from the same sequence, or in your case probably two sequences.  To do this, put all your channels with Timing = 1, offset = 0 in their own channel group, and then all the ones with offset = 0.5 in another group.  Let's say you called them Opener1 and Opener2.  Then create two sequences that look something like this:

 

while(1)

   try

      channel.readGroup("Opener1")

      alarm.checkAlarms()

   catch()

   endcatch

   delay(1)

endwhile

 

The second sequence is identical except its Opener2.  In fact, you might want to make just one sequence function that looks like this:

 

function poll(string groupName)

while(1)

   try

      channel.readGroup(groupName)

      alarm.checkAlarms()

   catch()

   endcatch

   delay(1)

endwhile

 

and two sequences that get run simultaneously that just call poll:

 

poll("Opener1")

 

What the sequence does is trigger all the reads on the group and then call the alarm checking once a group is done.  

[raining010]

Thank you, very detailed, I will try this

[raining010]

Hi, Mr Guru

 

Sorry, I don't understand the end of first graph of your reply. "a better solution might be to use the 40001.5 notation in DAQFactory as well.  Its a nice way of doing it, will run much more efficiently for you, and now that we have it so you can put strings in for channels, something that we can pretty easily implement for you."

Can I use 40001.5 in DF? And where can I input it, or do I need to define a function to do this?

 

About the alarms, it increases CPU load, but I think it's just a critical value. Without alarms, the program already occupy 20% of CPU. I think this due to channel events. If I move all these events into a sequence, and execute the sequence every second or two seconds, will this help to decrease the CPU load obviously?

 

Thanks

[AzeoTech]

I was suggesting maybe we needed to add such a feature.  We do not currently have it.  I would still look and see if coils works for you.

 

Its possible that a sequence would help.  It depends on the cause.  First check the CPU usage when you are displaying a blank page to be sure it isn't your user interface.

[raining010]

After many tests, I found that, alarms automatically scan costs CPU too much, after I pause alarm, and do interval alarm check, solve this problem, CPU from 20% to 10%

 

Events inside channels won't cost too much CPU,

and communications won't cost CPU too much,

graph displaying won't cost CPU too much

 

Thank you all

[AzeoTech]

Note that graph displaying uses the windows Idle thread, so although it may appear that a graph is using a lot of cpu power, its only using the cpu power available after all other windows items are done using the cpu.