RMA
Member
Since the code you wrote can actually be written like this,
code:--------------------------------------------------------------------------------
UN DB5.DBX0.0
= DB6.DBX0.0
--------------------------------------------------------------------------------
The code came from an earlier version of the program, which was a bit more complicated. After having unexpected (and still unexplained) problems, I decided to go right back to basics and make it as simple as possible by chopping everything that could be considered superfluous and in the process didn't bother to change the coding (more correctly, didn't think about it!).
There are no hardware errors in the CPU or in the two FM352-5s where the two parts of the test program are running (the demo prog on one and my one liner on the other). However, the third FM has the MMC that got screwed up in a previous thread, so it has an error. I tried just knocking it out of hardware config, but unfortunately it's in the middle of the bus, so not surprisingly that didn't work.
Nearly an hour later...
Finally decided to do the logical thing and remove the CP343 and the 3rd FM352-5 from the bus, as well as knocking them out of HW-config. That didn't take too long, but then after down loading every thing again, suddenly I've got parameterization errors on both FMs! Now obviously I've had to modify the second FM's access a bit because its address has changed, but nothing has changed on the first one. After many retries, compiling, downloading, saving and recompiling in HW-config and then downloading the whole program eventually everything is working fine. Evidently these beasts are extremely sensitive to the slightest change in configuration - anywhere! I suspect I now know where my original problems lay!
Anyway, now, with two FMs and no errors, we've got a cycle time of 10ms with occasional longer cycles of ~13 ms every 20 - 30 ms, so I assume that's due to some internal housekeeping in the CPU. Still seems a bit long to me, considering nothing else was running, but at least it's more reasonable.
So it looks like the error on the third FM was responsible for the excessively long cycle time. In the meantime, the 4 MB MMC for the CPU has turned up, so I can do the firmware update on the CPU and then take the CPU's 128 kB MMC to replace the duff one in the 3rd FM, put everything back together and see what we get then. Actually the 4MB card has just arrived at the right time - the main program has just got to the point where it didn't fit in the 128 kB any more!
I'll report back once I get everything back up and running.
Monitoring online will cause the cycle to increase, if you want the update time connect a scope to the output and check the cycle.
That's how I've been doing my time measurements, but it possibly explains the difference between the measurement and the cycle time shown in the diagnostic panel. Incidentally that difference has also reduced - the diagnostic panel is now showing a cycle time of 11 ms with just occasional drifts to 10 or 12 ms.
Cheers
Roy
Edit: Just thought I'd have a quick look to see what happened to the times in Debug mode (not really expecting to see any significant change) so set the Bit in the VAT to iniate the change - BANG!!! both FMs down with internal fault!
Boy are these things touchy!
Last edited: