Jump to content
OMRON Forums

Resizing CompTables at runtime


JeffLowe
 Share

Recommended Posts

Is it possible to resize a CompTable at run time as long as the table defined at startup is large enough to contain the new one?

I have resized the table buffer to 16 meg (this seems to be a limit). All lower numbered geometric CompTables are defined, with the last table defined as Nx[0]=2000,Nx[1]=2000.

Reading and writing to this CompTable function as expected, up to and including Data[1999][1999]. However if I reset Nx[0]=600,Nx[1]=600, any write to CompTable[12].Data[0][0] or above returns a Struct Write Error.

In monitoring .Data[0][0].a, it appears that the address is overwritten and lists as a nan after changing Nx[0] or Nx[1].

 

is there a way of undefining a CompTable, and freeing its memory as long as it is the last table to be defined? This would permit a new table to be defined.

Similarly, we have several machines, with differing travel and desire to size a prototype comp table for the longest travel, and then at runtime resize for the actual machine travel. If tables are undefined because if this resizing, this will raise issues.

Link to comment
Share on other sites

  • Replies 8
  • Created
  • Last Reply

Top Posters In This Topic

When you size/resize a CompTable using Script commands, Power PMAC automatically handles the memory management issues -- moving entries in the data buffer around, etc. to handle the newly declared size. This "under the hood" action makes it a lot easier to set up tables, as you are much freer to define and change tables than you were older PMACs.

 

However, it does means that the apparently simple operation of setting an Nx value in the Script environment actually triggers a big set of actions to keep the entire table data buffer correct. When you set an Nx value in C, none of this happens.

 

For this reason, you really must use the Script environment to change table structures, sizes, etc., even if you use C routines to fill the table data.

Link to comment
Share on other sites

When you size/resize a CompTable using Script commands, Power PMAC automatically handles the memory management issues -- moving entries in the data buffer around, etc. to handle the newly declared size. This "under the hood" action makes it a lot easier to set up tables, as you are much freer to define and change tables than you were older PMACs.

 

However, it does means that the apparently simple operation of setting an Nx value in the Script environment actually triggers a big set of actions to keep the entire table data buffer correct. When you set an Nx value in C, none of this happens.

 

For this reason, you really must use the Script environment to change table structures, sizes, etc., even if you use C routines to fill the table data.

My issue is I have defined a comp table near the limits of available table memory. Changing Nx simply tries to allocate a new table without freeing the memory previously allocated. Since I am at the limit, it returns CompTable[12].Data.a as a nan

Is there a mechanism to delete a comp table, freeing its data memory?

Alternatively, Can I change the Nx values from C and just rewrite the data in the comp table in the correct format?

Link to comment
Share on other sites

As you change table sizes, PMAC has to use new memory in the table buffer to ensure that the table will not overwrite an existing table. The only way to get the previously used memory back is to reset the PMAC, so it loads the tables from the start of the buffer.

 

I have no trouble setting my table buffer size greater than 16 MB. Set the size in the Project Properties window of the IDE (I set it to 64 MB), download the project, save it to flash, restart the PMAC with the reboot command, and reload the project. The Task Manager can confirm the size of the reserved buffer and how much you are using.

Link to comment
Share on other sites

As you change table sizes, PMAC has to use new memory in the table buffer to ensure that the table will not overwrite an existing table. The only way to get the previously used memory back is to reset the PMAC, so it loads the tables from the start of the buffer.

 

I have no trouble setting my table buffer size greater than 16 MB. Set the size in the Project Properties window of the IDE (I set it to 64 MB), download the project, save it to flash, restart the PMAC with the reboot command, and reload the project. The Task Manager can confirm the size of the reserved buffer and how much you are using.

 

This is a memory leak and in our machines will eventually fault in hours, not weeks or months. Is there a reason why the resizing, which will always be smaller than the original, cannot take place in C to preserve the pointer to the Data array?

Link to comment
Share on other sites

  • 2 weeks later...

The present algorithm was designed to ensure that memory conflicts could not be created as tables were entered in development. We are looking to see if there is a way around these protections.

 

Just a follow up in case anyone else is interested.

 

Setting the CompTable[n].Nx[0] and CompTable[n].NX[1] do not initialize the pointer to the .data array. This is done with the first CompTable[n].Data[0][0]=0

All of these have to be executed through the Command call, or by gpascii.

Once executed the following pointers work fine.

float *compdataptr;

compdataptr = pshm->CompTable[12].Data + OffsetTblSHM;

 

Item .Data[j] is addressed by *(compdataper + j*CompTable[n].Nx + i)

Link to comment
Share on other sites

  • 2 years later...

The present algorithm was designed to ensure that memory conflicts could not be created as tables were entered in development. We are looking to see if there is a way around these protections.

Meanwhile have you found "a way around these protections"?!

 

Also important how to free table-buffer, since save-cmd takes quite some time (minute) if 500MB are in use.

Link to comment
Share on other sites

We have not found a general robust solution. The vast majority of users do not change their table structures much at all.

 

If you don't want to save your tables, try setting all of the Nx elements to 0 before you save, and then write toData[0]. I think it will go much quicker if you do this.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share


×
×
  • Create New...