Near Intersection of I-35 & I-90 Southern Mn. | As a test yesterday, I brought up the bushel counter which was at a fairly high value since I had not reset it this year. I pushed the button to reset it to zero and it jumped back to zero before I got my finger off the screen. I repeated the procedure with the other bushel counter and the response was instant also.
In other words, I am not noticing the slow response that you are observing. One thing that is different between our setups is that you mention using a hotspot to connect to Ag Finiti. I am not doing that. I use Ag Finiti mobile on my iPad but the communication to it is only done when I change fields or force a batch transfer for a field.
I suspect your speculation that using the hotspot and cloud based Ag Finiti is the cause of your sluggishness is likely correct. I would think that others might be in your situation and could relate to your observations.
As mentioned I have this years planting, spraying and harvest to date on my InCommand 1200 in the current active year. Old data is still present but is stored in a previous year that was the active year at the time it was current. Our operation is small but between planting, spraying and harvesting there are several instances for this active year which don't seem to be causing any sluggishness.
I do remember a sluggishness situation many years ago with a PF3000. The PF3000 would become sluggish if it was overwhelmed with too much GPS information. Since the PF3000 was rather primitive by today's standards, giving it more than the basic GPS information that it needed caused it too slow down. The solution there was fairly simple, just change the NEMA output strings and BAUD rate to the settings that were appropriate. I don't believe GPS is your problem but is somewhat along the line of data overload. I think removing the old data would be worth a try.
The fact that your systems seem fine at first but develop the problem through the day seems strange. I've played with microcontrollers a bit and a concept called interrupts is often used. An interrupt can cause a quick diversion in the normal program flow for a specific reason. The interrupt should be very short in nature so it doesn't cause much of a delay in the normal flow of the program. With proper use, the very slight delay is not noticeable. There can be more than one interrupt involved which have a priority arrangement. It almost seems that these interrupts may be happening too often and so frequently that the other normal operations are being delayed for an unacceptable delay. This is pure speculation on my part and even if correct doesn't really help you.
Good Luck.
Edited by tedbear 9/29/2024 07:59
|
Incommand 1200 very slow to respond
