bradp

Greg, Attached is a video for you to use to recreate the problem. Please look at this and let us know what we are doing wrong or when we can get a fix for this. 2023-12-19_gpascii hangs when rotary buffer is full.mp4

I verified this is a problem using fw 2.7.1.0. You are not doing anything wrong that I can see, there seems to be a problem in gpascii or deeper.. I can not fix fw, I can just report the problem. Since I can not say how long it will take for a fix, if you have a work around I would consider using it.

I know there are plans but I have no information on schedules, that is up to ODT.

You can see the total transfer & receive times in the structures Sys.RxTime and Sys.TxTime. The time is not linear, so you can not just take the time for one 32-bit register and multiply it. You can come a little closer having the "base" value of a basic operating setup then seeing what happens when you add more PDO's for your drive or IO. Having said the above, optimizing is just eliminating unused data from the PDO's. Transfer less data & less PDO's and your Rx & Tx times will decrease.

could try a fortran to c converter. After the millennial problem they should be very mature.

At this point I think the next step is to get your project and try to duplicate the problem here. Please contact fmacaluso@deltatau.ch. He will of course ask some questions to come up to speed and will want the project to start testing and trying to duplicate.

when will the ctrlpanel[] structures be added to the documentation?

You do not need to add it to your PLC. For download testing just remove both of these from the pp_startup. Then if you can download several times with no problem we can assume the starting of these features is making the download problem. Also make sure UserAlgo,CFunc=0 before you do any downloading.

Just for a test can you make sure all C-programs (cplc, capps, usercode) and script PLC programs are stopped before you download. And make sure nothing is started automatically during download. This would include setting the useraldo.cfunc=1 if you are doing this.

after you load the new firmware you must issue $$$*** then save the $$$. Then you must redownload the project and all motor settings. Then open system setup and redownload the .eni file. Again do a save and power cycle the slaves and the CK3E

Eric, I understand some things are easier to handle through support and phone calls. But it would be helpful to end this thread with the resolution that you finally find. Otherwise everyone else who has this or similar issue can not use the forum to fix their problem. So please, once you know the solution please add it to the thread.

If the project is a new project and resident on the local drive, no network and no share, then I am out of suggestions at the moment and I think someone from ODT support in USA needs to pick up this thread.

Might be added to a docked window in a tab group.

In general terms you are not correct. The segmentation time can be larger than the time for one move block. This is very common. If this is desired depends on the specifics of the trajectory and application you are doing. In this case you must think of two things. First, the segmentation will curve fit the trajectory with a cubic profile. So you will not see features in the trajectory smaller than the segmentation time. Second is that synchronous assignments are executed at the segment boundary. If you have multiple move blocks in one segment then all synchronous assignments will be triggered only at the boundary. What I understand from your application is that you need an output for every move and you are doing this by synchronous assignment. So unless a different method is used, you should not have move blocks smaller than segmentation time.

When will the Modbus structures be added to the SRM & User's Manual? In IDEv3.1.0.6 there is nothing in F1 help about Modbus, you must manually navigate in the help menu to find it.