Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
C.S. Definition from PLC code (revisited)
#1
Hello,

I found reference to this in an old post:

http://forums.deltatau.com/showthread.php?tid=42

Are we going to be able to define C.S. from PLC programs at some time? We do all our configuration of the PMAC through code (usually an Initialization PLC of some sort). Right now I am calling an init PLC from C code and then turning around and defining the coordinate systems from a command() call.

KEJR

Reply
#2
When that post was written we had no CMD"" ability in script language. Now we have that ability so you can do this using CMD statements.
Reply
#3
I did try using the cmd"" call but it barfed on me at compile time with this error:

initplc.plc:77:1: Preprocessing Error: Prog Buffer Open: on string:" cmd "&1#1->1X"

Any ideas?

(01-14-2011, 02:41 PM)bradp Wrote: When that post was written we had no CMD"" ability in script language. Now we have that ability so you can do this using CMD statements.

Reply
#4
So what is your firmware version and date? Enter Vers and enter Date in the terminal. The command is valid.
Reply
#5
Welcome to PowerPMAC terminal
Select device to start communication
Telnet communication to PowerPMAC successful
Please wait!!! database Sync in progress
Database sync complete
vers
1.2.1.5
date
Jul 14 2010


I do have a new linux kernel from you guys that has the USB<->RS-232 support, but I doubt this has anything to do with it, just wanted to mention it.

Thank you,
KEJR
Reply
#6
KEJR,

I was able to duplicate your problem, but only if I select the "build and download" or "build" option. Downloading the script PLC by itself won't cause any errors. I have to figure out why the preprocessor is looking into the script files. I have reported a bug and you can track the fix process here: http://forums.deltatau.com/bugzilla/show_bug.cgi?id=338

Regards,
Sina Sattari
Chief Engineer
Delta Tau Data Systems, Inc.
Reply
#7
Sina,

Thanks for looking into this. We are OK right now with defining it in our C code via Command(), but it is good that it is being fixed so that in the future we (and others) won't have this problem.

Thanks,
KEJR


Reply
#8
This is fixed in the Jan 2011 IDE release.

The problem was having the # character in the cmd string triggered some parsing logic in the build cycle that it should not have.
Reply
#9
(01-18-2011, 11:08 AM)bradp Wrote: This is fixed in the Jan 2011 IDE release.

The problem was having the # character in the cmd string triggered some parsing logic in the build cycle that it should not have.

Brad,

Is the Jan 2011 IDE released to everyone yet? If so, where do we find it?
Reply
#10
It is not released yet. When it is there will be a post on the forum and the link to the IDE will go to the new release. It is probably 2 weeks away.

Do you need this specific feature or just want the newest?
Reply
#11
(01-19-2011, 04:18 PM)bradp Wrote: It is not released yet. When it is there will be a post on the forum and the link to the IDE will go to the new release. It is probably 2 weeks away.

Do you need this specific feature or just want the newest?

Thanks Brad,

We just want the newest IDE. We are having a lot of problems with the Motor Setup feature changing settings, forgetting settings, etc. It has frustrated us to the point where we avoid using the Motor Setup page at all costs. We did use it successfully for setting up an ACC-24E2A brush motor (one of your old blue demo boxes that we still have here).

Incidentally, can you point us to a script example of a motor, encoder, and coordinate system setup for a commutated motor with sinusoidal feedback on the ACC-24E3. We have gotten various pieces of that working but can't seem to put it all together. Part of the problems we have been having are related to the fact that the Motor Setup screens were changing variables we had already set. And just yesterday, we discovered that there is apparently an order in which some of the variables must be assigned. For example, our latest discovery is that we can no longer set the AtanEna=1 (we had that working on Monday but not yesterday). When we change it in the terminal window, it accepts the command, but the value stays at zero.
Reply
#12
I will get back to you on the other things. The AtanEna issue sounds like you did not set Sys.WpKey=$AAAAAAAA
Reply
#13
Yes. We figured out the WpKey issue today and now understand the commutation settings and various scale factors. We're now jogging our commutated motor and are in the process of tweaking the tuning and other parameters to our liking.

One of the things we ran into during our PLC scripting was that we had to specify the AmpEnableBit and AmpFaultBit values at the end of the script, otherwise, the values we specified were changed (like some other assignment was resetting them). We haven't yet tried to figure out which assignment was responsible.
Reply
#14
Incidentally, do you know if it is possible to set the encoder scale factor such that 1 cnt = 1 engineering unit (i.e. 1 degree or 1 millimeter)? This, of course, would require very high gains and a coordinate system definition of 1, but it would allow many of the parameters to be specified in more convenient units (particularly if the velocity and acceleration calculations were based on seconds instead of milliseconds).
Reply
#15
Many people do that with the scale factor. This is why you see in the manual we use units and not counts in the parameter descriptions. What we recommend however is that you set the ECT scale factor to give you counts as that makes sense for an encoder. You then set the motor scale factor to give you engineering units. Each gives the same end result but organizationally we like this way better.

When doing this watch out since many default values will be dangerous. For example, if you scale the motor to inches the default jog speed is now 32 inches per msec and the default FFE is now 2000 inches. And of course these scale factors are part of the control loops so your tuning will be affected.
Reply
#16
Thanks Brad. I think that is exactly the information we needed. We have traditionally used the Ix08 and Ix09 values to scale units to work well with fixed point scaling in earlier PMAC versions while the coordinate system was used to translate to engineering units. However, we have always wanted to work in engineering units at the motor level (including servo tuning). The motor position and velocity scale factors should allow us to do that for position and velocity. However, although we can scale velocity units by 1000 to make them in terms of seconds, I think the accelerations and jerks would still have millisecond scalars in the units. Do you agree? What we really want to scale at the motor level is the position and time base units (i.e. each differentiation applies the time scalar).

Reply
#17
For what its worth I just set up my motor (attached to ballscrew) and tuned it in motor units of inches. After a conversation with Sina on the phone I changed my scaling from ECT to the Motor[].PosSF and Motor[].Pos2Sf.

It really rocks to have your following error set to real units in the plots and settings screen. I currently have mine set to 0.010" which is 10:1 conservative with the tuning I've acheived and moves I'll be performing.

17bit encoder + MACRO + Copley + 15Khz/7.5Khz speed = :o)

Also, anyone using Copley drives in torque mode with MACRO should consult them as they have a fairly new option to synchronize the drive current loop with the macro update.
Reply
#18
Another Update:

After talking with Sina he had also mentioned setting up a file in the global includes to do all of the system setup. I don't know if this is documented or not but I was doing all my system inits in a PLC file.

By moving all of the setup info into a .pmh file it is like "downloading" setup files to the old PMACs and when you do a Save operation it saves the parameters.

This approach is great for folks like me who prefer to have all of the setup information in a human readable file. So in the end, I don't need the cmd" " fix for PLCs afterall, but it is good to know that the bug fix is there.

KEJR
Reply
#19
Personally, I would not try and change time units by adjusting a position scale factor.
Reply
#20
(01-26-2011, 10:09 AM)bradp Wrote: Personally, I would not try and change time units by adjusting a position scale factor.

No, I am adjusting position units only at this point to get it in inches of travel. Did you mean to reply to my other thread?
Reply
#21
This was in answer to Michaels question who also wanted to work in seconds not msec. I personally do not like doing that since it usually ends in mass confunsion although there are tricks to make it happen.

http://forums.deltatau.com/showthread.php?tid=391
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)