Setting up a CompTable from a background program

[gshort]

Is it possible to set up a CompTable entry from a background program. I seem to be able to set up a majority of the fields in the table from a background program and view them from a gpascii terminal and they all seem to be initialised as I expect. The one field that is not correct, however is the Target[] fields which I'm attempting to initialise to Motor[].CompPos.a. I've tried a variety of ways of doing this. However whenever I initialise Target[] from the background program it always appears to be 0 afterwards. Is this because the Target[] pointers are not accessible or am I just doing it wrong !

 

Thanks

Graham

[curtwilson]

I have no trouble setting this from a background program. Can you isolate it to a very short program and try it? I did:

 

open plc 7

CompTable[0].Target[0]=Motor[6].CompPos.a

disable plc 7

close

 

enable plc 7

 

and the setting took effect as expected.

[gshort]

Your example shows it working from a PLC, which I can get working without any problem. What I was asking was whether it is possible to access this structure from a background program, using the pointer returned by GetSharedMemPtr(). What I've found by experiment is that I can set quite a few fields of the CompTable structure, but not the Target[] or indeed the Data[] fields. I've worked around the problem by using a series of GetResponse calls from the background program. It would have been nicer to have been able to access the structure directly, but I suspect this is not possible. What I was hoping for was a definitive answer as to whether it is possible or not.

 

Thanks Graham

[Omron Forums Support]

Do you mean a background C program, or a background Script PLC?

[gshort]

I mean C program

[Omron Forums Support]

Can you please post your C program that attempts to modify the Target[] registers?

 

You may be able to actually access the register directly easily from within the C program with the pshm pointer. Example:

 

pshm->CompTable[0].Target[0]=pshm->Motor[6].CompPos.a;

 

However, I do not have a Power PMAC CPU right now to test this. Let me know if it works.

[gshort]

Thank you for your reply. There are a few issues with it however:

 

1) You can't do "pshm->Motor[6].CompPos.a" from a background C program. This would imply that CompPos was a structure with a field named "a", but it's a double. This syntax only works in plc/pmc programs.

 

2) I did try setting Target[] to &(pshm->Motor[6].CompPos) but after setting it, if I printed its contents it was set to 0 afterwards. It looks as if the Target array is pointing at an area that I can't write to.

 

3) Since posting this thread, I've also had problems accessing pshm->CompTable[x].Data. This also appears to fail and indeed crash the system. I've since found another forum thread here http://forums.deltatau.com/showthread.php?tid=107 in which Brad mentions that although its possible to Read the Data[] field from the background C program, it should not be used to set up the Data this way. For this GetResponse should be used, and that is what I've done.

 

As you requested it, here is a fragment of the C program that I've cut from an old version of my program:

 

pCompTable = &(pSHM->CompTable[index1]);

pCompTable->Source[0] = motorNum;

pCompTable->Nx[0] = numElements;

pCompTable->X0[0] = start;

pCompTable->Dx[0] = span;

pCompTable->Ctrl = control;

pCompTable->OutCtrl = 0;

pCompTable->Target[0] == &(pSHM->Motor[motorNum].CompPos);

pCompTable->Sf[0] = 1;

 

I've now replaced this with something similar that performs a series of GetResponse calls to perform the same function. The GetResponse method appears to work fine.

 

Again, what I was looking for was a definitive answer as to whether the CompTable structure should or should not be accessed from the pshm pointer. If the answer is no, and it would be good to have some background as to the reason why not, it raises a more general question as to what structures are available for access from a background C program via pshm and which should be avoided.