Full Version: Code Execution Ahead/Behind Windows Clock - Need to be in sync
UtterAccess Forums > Microsoft® Access > Access Forms
Briandr
I have code within a form that is supposed to execute on a 60000 timer interval. I am guessing the code it is executing should take no more than 40 seconds to process. I am reading in data using DDE and appending to SQL tables. The problem is Access seems to behind the system clock time. Another words, the code executes at 11:52 and while it executes the system clock changes to 11:53. No data is grabbed for 11:53 since the program will wait on the timer interval before executing again. Can someone help? I had posted this previously and someone attempted to help, but he was deferring to other members. I am attaching this small app and the question if not asked before is how to get it so that the access program and the windows internal clock both sync up together. I really would appreciate help. Thanks.
Edited by: Briandr on Tue Nov 1 14:08:57 EST 2005.
ChrisO
G’day Briandr
If you need it to run each 60 seconds I think your timer event will need to look something like this: -
CODE
Private Declare Function timeGetTime Lib "Winmm.dll" () As Long


Private Sub Form_Timer()
    Dim lngStart As Long
    
    On Error GoTo ErrorHandler
    
    lngStart = timeGetTime()
    
    [color="green"]' Do
    ' your
    ' thing[/color]

ExitProcedure:
    On Error Resume Next
    Me.TimerInterval = 60000 - (timeGetTime() - lngStart)
    Err.Clear
    Exit Sub

ErrorHandler:
    SendEmail Err.Number, Err.Description
    Resume ExitProcedure

End Sub
What you need to do is time the process and subtract that from the 60 seconds.
Naturally the process must be shorter than 60 seconds else you will get an overrun.
Hope that helps.
Regards,
Chris.
Briandr
Hi Chris,
Thanks for the reply. Much appreciated. Couple questions. First, how do I time the process to make sure I am under 60 seconds? As stated above I would very much be surprised if I am over 60 seconds. Second, do I just add in your code on my timer event or do I have to merge it in with my the code that is already there?
lngStart = timeGetTime() ' Do ' your ' thing
Does my code start right after this line?
I would really like to put something on the form that displays the time it took for the code to run. Can you help me out in that regard? If you could post your suggestions I would appreciate it. Thanks.
Briandr
Private Declare Function timeGetTime Lib "Winmm.dll" () As Long
This line of code is producing a compile error:
Only comments may appear after End Sub, End Function, or End Property
ChrisO
If you open the Old Code form and display the system clock you should hear a beep 10 seconds later.
It that time a dummy timing loop starts and runs for about 30 seconds on my machine. When the timing loop terminates the time will be displayed in a text box. 60 seconds after the original beep you should hear another beep when the process starts again.
During the beep and the update of the time the form will not respond because the loop is running. This may or may not happen if you substitute your code for the timing loop. I don’t know and can’t test it.
There are many more considerations to be made when dealing with hardware such as if the PLC goes down or the link is broken. So this is just a simple timing test.
Hope that helps.
Regards,
Chris.
Briandr
Hi Chris,
up, the timer went off about 10 seconds after the form opened. According to the box the code ran for about 14 seconds. Then every 60 seconds thereafter the same time of 14 seconds was displayed. Now granted this is on my computer and not on the computer that communicates across the LAN via DDE. Let me address your comment/concern regarding the other thing such as the PLC going down or the link being broken. The link should never get broken. To my knowledge it never has. Now if you examine my code in the other form you see I am accounting for the PLC being down. If its down, I don't want to grab data and it shouldn't. My concern is that I have a similiar program that is grabbing data from another PLC and I never had "skipping issues". Maybe the number of recordsets is contributing to this being slown down or it could be like you said the link across the LAN via DDE, but as mentioned I don't think it is. Can you tell me how to insert your code into my existing code so I don't get these compile errors? I will also run this new code on the computer hosting the program so I get an idea as to how long it is taking.
Thanks Again frown.gif
ChrisO
Glad it’s starting to work correctly.
If you open the Old Code form you will notice I changed you timer event name to OldTimerCode.
If you look into the new timer event handler you should see where the old event can be called from, it’s commented out at the moment.
Uncomment that line and remove the dummy timing loop.
Osuspect the compile error is because the line
Private Declare Function timeGetTime Lib "Winmm.dll" () As Long
is not up at the top of the module.
Hope that helps and good luck.
Regards,
Chris.
Briandr
Hi Chris,
haven't had a chance to get back to this since I was out of work last week for two days. I am interested in seeing this resolved. I will check the timer to see how long the code is executing for and I will also insert your fuction at the top of the code in the form. I will let you know how things turn out.
Briandr
Hi Chris,
want to review so we are both on the same page. I am not a programmer by trade and I can get lost in the code at times. You said you made modifications to a form I had called Old Form. I see those changes. You also said you made modifications to the original TimerEvent code. I don't see that. Maybe its staring right at me. As far as the OldForm, I just assume throw it out and use the code in the PLCLogger form. I tried implementing your code in that form. It appears my original code is running and your code to check how long its running is not. I say that because I continue to log my data and it never tells me how long it took to process the code. What I would like to do is include your code permanently in that form, minus the beep. I am attaching the database again. If you could help me sort through the code, I would appreciate it. Thank you.
ChrisO
I removed the old form made the changes, decompiled, recompiled and compacted.

Ocan’t test it because I don’t have a spare PLC hanging about, but it should work.

If that works OK then the next thing to do would be to divide each mill into its own scan and call each mill in turn. That way, if you get a problem with the code you will be able to comment out any of the scans which would make it easier to debug.

Hope that helps.

Regards,
Chris.

Edited by: ChrisO on Thu Nov 10 17:49:17 EST 2005.
Briandr
Hi Chris,

Oput this code into realtime and the execution time is ranging from 55 - 58 seconds. I could be collecting data from 5 pieces of equipment at any given time. When I was collecting data with your timer in place 4 of the 5 pieces of equipment were running. I bet if all 5 pieces of equipment were running my code execution time would probably be about 70 - 80 seconds. As our manufacturing environment evolves and more data is needed to be collected I am going to continue to have the same problem. I really don't want to have 5+ small Access programs running, 1 for each piece of equipment. So I guess I need to do a code clean up or separation of sorts to fix this so I won't lose data. I know the form itself has the on timer to call code from, but the text box doesn't. I'd like to keep the PLCLogger form because it is informational and gives you a status on all the equipment. There should be a way of doing this. I just don't know how and if you can help I would appreciate it. Thanks.
Edited by: Briandr on Fri Nov 11 9:43:44 EST 2005.
Briandr
I am a little confused. Perhaps you could explain how your code is working either here in this forum or with comments above your code. What appears to be happening is that the program is not waiting a full 60 seconds prior to collecting new data. It appears that as soon as it finished looping through the code it is waiting a few seconds or not at all (maybe its my imagination) and then resumes grabbing the data. Am I missing something here? I am also curious to see how what I described above this post can be fixed.
ChrisO
G’day Brian.
It is just a fact of process control life that you can not run an 80 second scan every 60 seconds. The time between scan starts must be longer than the time it takes to do the scan else you get a scan overrun, what is normally called a process block overrun.
In a process control computer, if a scan was scheduled to run every 60 seconds, the operating system would terminate the scan if it tried to run over the 60 seconds. The scan would then be restarted on the 60 second interval but if the scan overran again and again then the scan would be de-scheduled.
So if we are looking at a possible 80 second scan then we will probably need to schedule the scan starts for every 120 seconds.
Now because the scan durations will not always be exactly 80 seconds we need to time the duration and subtract that time from the schedule time. For example, if the scan is scheduled to run every 120 seconds and the scan takes 80 seconds we reset the timer event to 40 seconds. A scan starts and 80 seconds later the timer is set to 40 seconds. 40 seconds later the scan restarts and takes 80 seconds to run and the timer is set to 40 seconds. 80 seconds runtime and 40 idle time = 120 seconds schedule time.
This all assumes that the timer will not run during a scan. I don’t know if that is the case with DDE and to make sure it needs testing, which is something I can’t do. To make sure that the timer does not run during a scan, you should be able to turn it off just before starting the scan and reset it at end of scan.
Does that make any sense?
Regards,
Chris.
Briandr
Chris,
Y,
Your probably one of the only people here at Utteraccess I have spoken to that has a knowledge of PLC's. That's good and I appreciate the help. I am lost yet again. I have read through your reply a couple times and still trying to grasp it. Lets try to break it down this way. Say I was only collecting data via DDE from one piece of equipment in the Mill and thats it. The amount of code in Access would be alot less since we wouldn't be dealing with other pieces of equipment. So if in that one piece of equipment I am pulling in say 20 data variables associated to it, DDE should be able to complete the last scan without a problem and append the data to the appropiate table. I know this to be true because we have another piece of equipment in another department and I am able to get the data for the last variable (I think there is 20 or 25 variables) pulled in before the timer goes off. Are you with me so far? I hoping this is making sense. As far as the scan times they have to be every 60 seconds. As I write this I am thinking that the scan themselves are part of the problem in that its taking so long, but the other code is probably also bogging it down too. That is why I am suggesting each section be branched off with its own timer, that way its not dependant on the other code finishing before the next scan.
Let me know what you think and sorry if I didn't directly address a question you posed.
ChrisO
I think that what you will be faced with, on any one PC, is the total time to do the scans. The scheduled starting time can not be shorter than that total time.
aving more than one timer would not help because if a timer stops, because of DDE, then all timers would stop. The timer is not an interrupt it’s a polled service and a fairly low priority one at that. Just holding down a mouse button will stop the timer.
So back to the problem of time. If a scan must run each 60 seconds then the scan period must be less than 60 seconds. If the data sampling is that important then perhaps each mill should have its own PC. Considering the cost of PC’s these days that would not be a bad way to go since you would not loose all data if one of the PC’s went down.
But as it stands it seems to me that there is too much data being transferred and not enough time to do it.
Regards,
Chris.
Briandr
Ok. I do understand that if the internal access timer stops then all timers would stop, but I don't think that would happen. I have never had the timer stop on me before.

Let me throw another scenario here. What if its not the scan time, but rather the total code execution time? Every minute for each record set I am going to scan for say 20 variables. How long does it take for Access to scan them via DDE put them into a temporary memory location and then continue executing the code prior to appending the data to an appropriate table? We don't know that. What we do know is the code execution time will be delayed by the scan time, correct? That is why I was suggesting breaking this down into separate timers or separate modules. As I mentioned above I am not having this issue with another PLC in another department and I am scanning for about the same number of modules. I am winging this because there is a chance I might be right. Now under the assumption your correct how do I time the scan time? Can I do it for each piece of equipment?

Since I implmented your code I notice that the same problem continues to exist as far as skipping records. That should not come as a surprise since it is going past the 60 seconds, I think. The sole reason for your code was to track the execution of the code and to keep the internal access 97 clock tied to the windows 2000 clock, nothing else? Been a long day so maybe I missing something. This is why I am not a programmer, I don't have alot patience with this stuff. In fact most of what you seen was code given me by others to get this thing going. I'll keep trying and anything you can suggest or code modifications I'd appreciate.



Edited by: Briandr on Fri Nov 11 15:24:35 EST 2005.
ChrisO
“The sole reason for your code was to track the execution of the code and to keep the internal access 97 clock tied to the windows 2000 clock, nothing else?”
orrect, that was your original question. grin.gif
The method of timing used is to call the API Function timeGetTime that returns a long millisecond count since Windows started. The scan code is processed and a second call to timeGetTime is made. The difference between the two values is the total time for the scan in milliseconds.
That total time is subtracted from the desired schedule time so that the timer event can be triggered at the scheduled time.
But that would only work under two conditions…
1. The timer does not tick during a scan, if it does then turn the timer off during a scan.
2. The total scan time is less than the desired schedule interval else the subtraction would produce a negative number.
HAs for dividing it up into chunks of coding, I really don’t think that will work. For whatever the reason for the delay, code execution, network delay, PLC turnaround time, there is a certain amount of work to be done. That amount of work requires a certain amount of time depending on the efficiency of each of the related components. For example, if you are running on a slow network it will take longer, but how much longer I haven’t a clue.
Access won’t multi task us out of trouble, the timer event will stop for almost any reason and we can’t put 80 seconds of processing into a 60 second time slot.
What I will do is divide the code into separate mill scans and post it back to site. It won’t improve performance one iota but it will allow taking each mill off scan so you can test it.
I’ll try to have it back by your Monday morning but since this is all free please don’t complain if I’m late. grin.gif
Regards,
Chris.
Briandr
Hi Chris,
I am never one to complain and thanks for the help thus far. Before you dive into the code and start working it I got a question. Don't I already have separate DDE scans? What I mean each section has a condition where the DDE request is only called out if the equipment is running. What do you have mind for what your planning on doing? I am thinking I still may pursue having one separate small program for each piece of equipment. I am not sure and the other thing I just realized is the CTI2572 card that is in my PLC is only communicating at half duplex. I may need a card upgrade. Somehow, someway this will work the way its intended to. crazy.gif
ChrisO
Yes you are correct. I missed the run flags in the Form Load event.
I was intending to use check boxes on the form to bring each mill into or out of scan but those flags will do the same thing.
I’m not at all familiar with the CTI2572 card you mentioned but can the transmission rate be increased? Sometimes people set the transmission rate to a low value to improve noise immunity.
Anyhow…have fun and good luck.
Regards,
Chris.
Briandr
Hi,
One of my colleagues suggested changing a setting on the PLC. That helped out quite alot. I ran your old code and it seems to be about 47 seconds total time. Thats good! I am actually under 60 seconds, that is assuming your code is reporting the execute time correctly.
I been reading through all of the posts under this topic and just wanted to ask one thing.
"Now because the scan durations will not always be exactly 80 seconds we need to time the duration and subtract that time from the schedule time. For example, if the scan is scheduled to run every 120 seconds and the scan takes 80 seconds we reset the timer event to 40 seconds. A scan starts and 80 seconds later the timer is set to 40 seconds. 40 seconds later the scan restarts and takes 80 seconds to run and the timer is set to 40 seconds. 80 seconds runtime and 40 idle time = 120 seconds schedule time."
In your last piece of code your not adjusting to accomodate the scan time, right? This is the last piece I have from you and am using.
Private Sub Form_Timer()
Dim lngI As Long
Dim lngStart As Long

On Error GoTo ErrorHandler

lngStart = timeGetTime()

Call OldTimerCode
Me.txtDisplayDuration = (timeGetTime() - lngStart) / 1000
DoEvents
ExitProcedure:
On Error Resume Next
Me.TimerInterval = 60000 - (timeGetTime() - lngStart)
Err.Clear
Exit Sub
ErrorHandler:
SendEmail Err.Number, Err.Description
Resume ExitProcedure
End Sub
All we are doing here is making sure the timer code is sync with the Access clock? I believe we are doing nothing more. If that is the case we are looking good at 47 seconds, but more data may be scanned in and ultimately I may have to upgrade the card or the procesor in the PLC.
Thanks!
ChrisO
That code is adjusting the timer interval based on the time it takes to make a scan.
You are OK at 47 seconds and will continue to be OK up to 59.999 seconds but not beyond.
Regards,
Chris.
Briandr
I am actually toying around with the idea of whether or not I need your code to control the sync. I thought I noticed something weird happening when it was running, but I am not sure so a further observation time period will be needed. Might have been my imagination though. When I was running at 47 seconds, all of the equipment was running. If I decide to keep using your code can I change how it keeps thing in sync or are you saying I don't need to change it? I get the impression it will be fine as you indicated up to 59.999. As far as the code I looked at it a couple times and still trying to understand it.
e.TimerInterval = 60000 - (timeGetTime() - lngStart)
Are you essentially zeroing out prior to subtracting from 60000?
That appears to be the case and I am just trying to understand how the code works. I'd like to at least understand what the code is doing.
Thanks again for the help.
ChrisO
“I'd like to at least understand what the code is doing.” Nothing wrong with that.
e.TimerInterval = 60000 - (timeGetTime() - lngStart)
timeGetTime() = millisecond count since Windows start.
lngStart = count at start of scan
(timeGetTime() - lngStart) = scan period
Me.TimerInterval = 60000 - (timeGetTime() - lngStart)
Sets the timer interval to 60 seconds – scan period
So provided the scan period is less than 60 seconds the timer routine should be called every 60 seconds.
Odon’t know the reason to stay with the 60 second time schedule.
If it is being done at that rate simply to trend data or calculate rate of change then you should be able to interpolate values for the 60 second period from a 120 second schedule.
But I don’t know how you’re using the data.
Regards,
Chris.
Briandr
We need to stay within 60 seconds to trend data over an extended period of time. I was told that by the team in charge of this project. What I noticed today that I didn't notice yesterday was 4 of the 5 pieces of equipment were going. So 47 seconds is not a true indication since not all the equipment was active at the same time. From what I been able to gather its pushing the button with 4 pieces of equipment going and I am getting times from 45 - 57. The fluctation does concern me but I realize there is other things going on. So what I did was open task manager and set the app to a 'run-time priority". Not sure if that will help, but I figured it could not hurt. I figure with all going at the same time it could go up as high as 120 seconds. Other things I have noticed is when this is running, it seems to hog all resources. Another words, I can't minimize it or change to the 2nd tab. It just freezes itself up and anything else on the system as well while its grabs the data.
I am exploring other options, but it appears I am not going to be able to get this to work the way I wanted. Any other thoughts or would you agree we have taken this as far as it can go?
ChrisO
“We need to stay within 60 seconds to trend data over an extended period of time. I was told that by the team in charge of this project.”
That does not make much sense to me. If you are trending data over an ‘extended period of time’ why do you need to do it every 60 seconds? It seems you could do it every 120 seconds and calculate the 60 samples. Being calculated values they would and should not be saved in the trend table but simply calculated on demand.
Odon’t know what you mean by ‘the team in charge of this project’ since it seems that you and I are doing all the work. As such I think we are in charge.
The thing that seems strange to me is that it takes almost 60 seconds to do around 40 DDE requests. One of the reasons might be that each DDE request retrieves only one value and each value is an unsigned 16-bit integer. The data might be transferred as 16 bytes (variant number) so the effective data transfer rate is around 12 bytes per second. Even if the data type was variant text 27 bytes, 22 for the variant and 5 for the text, it appears that 300 baud would handle it.
Why is it so slow? Are you running RS232 in a very noisy environment? Why not change to RS485 and push the speed up? Can you use fiber optics?
Ultimately you need to interface with a Siemens PLC so get on the phone to them and have a chat about the alternatives.
HAs for the form locking up during a scan I said this in my second post: -
“During the beep and the update of the time the form will not respond because the loop is running. This may or may not happen if you substitute your code for the timing loop. I don’t know and can’t test it.”
Placing DoEvents between each DDE call should free up the form somewhat but I think you will still get an average delay of around half a second during a scan.
Regards,
Chris.
Briandr
Hi Chris,
Not more information specifically regarding DDE. Let me get started by addressing your comments/questions.
Odon't know why the need to collect data every 60 seconds. I know that is what we are doing for our other PLC. I was just told to try and set it up this way. So I am not going to argue with the establishment and yes I am not getting the support I need to be, but that's another story for another time.
"The thing that seems strange to me is that it takes almost 60 seconds to do around 40 DDE requests. One of the reasons might be that each DDE request retrieves only one value and each value is an unsigned 16-bit integer. The data might be transferred as 16 bytes (variant number) so the effective data transfer rate is around 12 bytes per second. Even if the data type was variant text 27 bytes, 22 for the variant and 5 for the text, it appears that 300 baud would handle it."
I would agree it is strange that it is taking longer than 60 seconds to do around 40 DDE requests. I can't comment much further other than to say your probably correct in your assesment.
"Why is it so slow? Are you running RS232 in a very noisy environment? Why not change to RS485 and push the speed up? Can you use fiber optics?"
I believe it is RS232 and Yes it is a VERY NOISY environment. I would have to check with the PLC guy to see about a possible upgrade to RS485. I know he was looking into possibly using fiber optics or Profibus, for what reason I am not sure. This how the connection is from server to PLC.
PLC---> Slave Switch--->Main Switch--->Server--->CTI I/O DDE Server--->Access 97.
From the PLC to the slave switch we have a 10 / half duplex connection and the rest of the way back is 100 / full
Attached your going to see a couple screen shots relating to DDE. The first is from CTI I/O Server which shows the configuration page. The next is from Access 97 itself showing the DDE setttings. Remember I mentioned I thought I noticed something unusual? Well, apparently the form is not reflecting the status of the equipment correctly. Another words say the dark kettle goes down, the status on the form doesn't change from
"Dark Kettle is Running" to "Dark Kettle is Down". Data isn't collected, but for whatever reason the form is not reflecting the correct equipment status. Sorry for being long winded.
ChrisO
Ok.
irst thing to try is to drop the DDE update interval from 1000 milliseconds to 500 milliseconds on the CTI 2572.
See if it shortens the scan time.
Regards,
Chris.
Briandr
I will make that change tomorrow. What I am thinking is perhaps it would be a good idea to store the date/time & scan times in a table since they do change either by a little or by a lot. Then I can go back through that and see if changing the DDE update interval from 1000 milliseconds to 500 milliseconds made a difference. Is this something easy to setup. I am assuming it would be. Thanks.
ChrisO
Do you not already have the scan time displayed in Me.txtDisplayDuration?
That should be sufficient to simply display the scan duration.
It is entirely problematic if you store the time of each sample for each sample.
There are a few ways to go at this stage so please bear with me if it seems a little strange.
In the code, as stated so far, it appears that you are already saving the PC time and date at start of scan. But the code also seems to indicate that the original intention was to save the PLC time at start of scan. They are not the same things since someone could change the PC time but it would be very difficult to change the PLC time.
Consider if the PC shifted time automatically due to daylight saving. If the PLC does not shift time due to daylight saving (almost guaranteed) then the system and its data are screwed. So I therefore think the original intention was to save the PLC time at start of scan not the PC time.
Each individual measurement sample should have its own individual date/time stamp even if the date/time stamp is the same for many entries and leads to redundancy in the date/time field.
People may like to try and normalize that situation, to remove the redundancy, but they should first consider the nature of any sample. A sample exists as an event in four dimensions and as such can be considered atomic. Not all four dimensions are always required. Problem is that Access does not have a space/time data type.
Next problem is saving PLC time for each DDE request. If each DDE request is limited to one parameter, certainly not a given, then we suffer the overhead of both getting the sample and the PLC time. We double the network traffic and sample time…not a good idea.
HAs the code stands at the moment, I would be inclined to get PLC time, at start of scan, and save the millisecond offset for each data request using timeGetTime() on the local PC. One request for PLC date/time and one offset for each DDE call in milliseconds.
With that you can back-calculate each sample time without incurring excessive network traffic.
However, the first thing is to get the network up to speed.
Get the communications right and then we can discuss the content of the data.
Regards,
Chris.
Briandr
"However, the first thing is to get the network up to speed.
Get the communications right and then we can discuss the content of the data."
OChris,
Long time since we chatted about this and yes I am addressing the network issues. Its not the network per say in that I already have Cat 5 and can go at 100MBps / Full Duplex. The bottleneck I believe may be with the card in the PLC that is connected to the network. That is only capable of 10MBps / Half Duplex. The new card that I am testing out out will be capable of 100MBps / Full Duplex. I am hoping that makes an immediate difference. Then if problems still persist I am looking at upgrading to multi mode fiber from Cat 5. So we'll see what happens. I should have some data to check out by late this week or early next week.
Briandr
Hi Chris,

Got the new card for the PLC and it is running at 100 / full. Guess what ? No major improvement. Since you know a little about PLC's let me say this. Each PLC has a master and several remote bases or RBC's. For the best possible performance you want the ethernet card that in the master base whenever possible. In this instance the ethernet card is in a remote base. Sure that is going to affect things, but it gets better. On another separate PLC with its own master and RBC's, I have a ethernet card in the remote and am able to collect the same amount of data in less time. So now I back to looking at the code in the Access program. Is it streamlined? I noticed that when no machinery is running, its takes 8 seconds to loop through all the code. I thought it would be faster. Can we look at anything else or have you run out of ideas?
Edited by: Briandr on Tue Dec 20 11:18:19 EST 2005.
ChrisO
G’day Brian.
id you change the DDE update interval to 500 milliseconds and if so what was the outcome?
There’s a good chance that you are retrieving only one valve per second. Even when the plant is offline the code is testing for both PLC time and plant status. That could amount to the 8 seconds while the plant is offline.
Regards,
Chris.
Briandr
Hi Chris,
Yes, I did change the DDE update interval to 500 milliseconds and it did not seem to help. I spent a considerable amount of time with the manufacturer of the PLC card over the last couple of days. Unfortunately, these guys don't know much about Access or VBA. They do know how to use DDERequest, but only in Excel. They had me load Ethreal and run some tests. Apparently I got some pretty heavy TCP traffic on the server, which surprised them. It didn't surprise me since the machine is a server. We then ran it on a standalone machine running XP and the TCP traffic was even heavier. I don't know what is up with that since its got just XP and Office on it. We even tried using UDP with the client software (CTI I/O Server) and that didn't help alot. The one thing they were wondering was if the Access code was updating after each DDE request or waiting until the last one. If you look back at the code, it would appear the update takes place right at the very end. Would it make sense to read in the DDERequest and immediately update the database or could one DDERequest be sent for all the data points and one updat be done? These guys seemed sharp on the PLC side, but when it came to Access all they seemed to indicate was that the code itself, namely the multiple DDERequests was causing the inefficencies. I am hoping to get the Access gurus that I work with involved and then get these PLC guys on the phone together and hit this hard.
Happy Holiday to you and yours.
Brian
ChrisO
Well the only thing I can suggest is to hook up a CRO to the slowest point on the network and have a look at the timing.
If it appears to be operating only at regular intervals with no activity between bursts then the problem is probably software related. If there appears to be no break in transmission then the problem is probably hardware related.
That’s about the best I can suggest without actually being there.
Hope you get it sorted and have a Merry Christmas.
Regards,
Chris.
Briandr
I decided to split the database in two, reduce the number of DDERequests. We'll see if that helps or not. I have also decided to see if some others that frequent other Access Help Forums can help.

The other thing is would it be possible to read in a range of data points from the PLC using a single DDERequest command? I been checking out google and I am pretty sure its possible with Excel, so shouldn't it be possible with Access? If it is do you think that would improve the performance and speed up the code execution or would still be the same amount of time to loop through the code?
Edited by: Briandr on Fri Dec 30 10:14:59 EST 2005.
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.