Jump to content

SSC File transfer


---
 Share

Recommended Posts

I have a 5-way star probe on an RDS/XXT machine. The stylus system also has 44 additional styli at various rotations. On my Planner seat, I imported the SSC file of the star probe and then imported the "Star.txt" file created in the RC List window. I assigned the additional rotations and ended up with a stylus system that matches the one on the machine.

Now, I want to transfer this stylus system to another Planner seat. Is there a way to transfer the complete stylus system or will I need to repeat the process on the 2nd seat?
Link to comment
Share on other sites

Thanks. I was hoping that once a stylus system was "complete" from a simulation point of view, that there might be a new file that could be copied and pasted to the 2nd seat.

ding, ding, ding....if I copied the config folder to the second seat, would the stylus system transfered?
Link to comment
Share on other sites

If your seats are all the same you could perform a backup on seat #1 and then restore it on #2, I would think that should work as long as it's a newer version.

However this will backup and restore all machine tabs.

You could potentially copy the entire machine tab's folder to the other machine, then create a new tab in Calypso with the same name, it should prompt you saying that there is already one with that name, do you want to load settings?

Both should work I would think as they will move the probe database.
Link to comment
Share on other sites

Please sign in to view this quote.

Are there software version restrictions?
Example, copy data from v2022 to v2016?
Link to comment
Share on other sites

Please sign in to view this quote.


I seriously doubt you'd be able to go backwards that far. You might get a version or two.
Link to comment
Share on other sites

Please sign in to view this quote.

Do not go backwards. Ever.

I strongly advise against doing this in any cases. All versions of CALYPSO have some change to SQL/SDO structure. Changes to SQL/SDO may not immediately reveal the error in data structure from a future dated/versioned config. SDO errors related to corrupt configs (SQL db) are significant to overcome. If your baseline config used for backup/restores was a down-versioned config, your issues are bound to recur. "Well, I tried it and it worked for me" is not a statement of validation. And "worked" does not indicate all uses of config were tested and may fail at a later date.

This is no different than attempting to down-version an inspection plan. I understand the desire to circumvent effort and save time (production calls!) but the risks far outweigh the benefits.
Link to comment
Share on other sites

Please sign in to view this quote.

I have not tried it; I was curious of if or should not.
Pretty sure Jeffery answered that one. 😉
Link to comment
Share on other sites

 Share

×
×
  • Create New...