I'm having an issue where we execute an MC_CAMIN instruction. Sometimes the instruction never transitions from Busy to Active, even after the master axis passes the MasterOffset value (in my case, 5.0 degrees). 95-98% of the time, the CAM executes and goes active perfectly fine, but very occasionally, it does not. When this happens, there is seemingly no error or error ID.

My main question is: What conditions would cause the MC_CAMIN instruction to not transition from Busy to Active? 

Attached CAM instruction for reference.

Tia Portal V15.1

Instruction V4.0

S7-1516TF-3 (FW V2.6)

Accidentally I stumbled upon this thread and I see that my thread is more or less similar.

Let me add one IMPORTANT thing : the chance of success ( so the MC_CamIn succesfully launches the cam and doesn't stay stuck ) is inversely proportional to Master's speed.

If master runs slow, it seems that the MasterSyncPosition is "detected" correctly and all is fine.

If master runs "fast" (and I strongly think that it depends on the CPU's performances, since in my 1511T the "Fast" means 360°/s !) then your chances to have a stuck MC_CamIn are high.

The "funny" thing is that in case MC_CamIn is stuck, if you reduce the master's speed, it unfreezes and starts working immediately (when master crosses the next sync position) !

More precisely you have the "Busy" flag at TRUE from MC_CamIn, but you will never see any InSync flag coming (in fact slave never moves).

Additionally no error flag/IF is present. MC_CamIn instruction does not give any error.

@Siemens : it does definetly depends on Master Speed. Please fix this, otherwise we cannot do serious machines with T-CPUs. It is realyl IMPORTANT.

Affected TIA : TIA 20

 Davinator

Accidentally I stumbled upon this thread and I see that my thread is more or less similar.

Let me add one IMPORTANT thing : the chance of success ( so the MC_CamIn succesfully launches the cam and doesn't stay stuck ) is inversely proportional to Master's speed.

If master runs slow, it seems that the MasterSyncPosition is "detected" correctly and all is fine.

If master runs "fast" (and I strongly think that it depends on the CPU's performances, since in my 1511T the "Fast" means 360°/s !) then your chances to have a stuck MC_CamIn are high.

The "funny" thing is that in case MC_CamIn is stuck, if you reduce the master's speed, it unfreezes and starts working immediately (when master crosses the next sync position) !

More precisely you have the "Busy" flag at TRUE from MC_CamIn, but you will never see any InSync flag coming (in fact slave never moves).

Additionally no error flag/IF is present. MC_CamIn instruction does not give any error.

@Siemens : it does definetly depends on Master Speed. Please fix this, otherwise we cannot do serious machines with T-CPUs. It is realyl IMPORTANT.

Affected TIA : TIA 20

This very well could be but I don't believe I am specfically seeing that. In my application it is two linear axes. I am using a 1514SP TF on V20. I wouldn't necessarily say the master is running fast. We are bending a part with a servo (Slave) relative to material travel (Master). The master is running ~150mm/s. Scan time of the PLC results in about 1-2mm of Master travel per scan. MC_CamIn is executed when Master is reset to 0mm position. The CAM profile keeps the servo at the same place until Master position ~50mm, so we are well within the bounds of the CAM profile when the MC_CamIn is executed. 

Is your CAM profile hard coded? Or are you changing it with the user program? If an adjustment is made on the HMI I use the LCamHdl_CreateCamAdvanced Siemens-built FB to recreate the CAM profile. It seems that adjusting the CAM profile between cycles causes the problem to happen more often. 

Luuuuuuutz

 Davinator

Accidentally I stumbled upon this thread and I see that my thread is more or less similar.

Let me add one IMPORTANT thing : the chance of success ( so the MC_CamIn succesfully launches the cam and doesn't stay stuck ) is inversely proportional to Master's speed.

If master runs slow, it seems that the MasterSyncPosition is "detected" correctly and all is fine.

If master runs "fast" (and I strongly think that it depends on the CPU's performances, since in my 1511T the "Fast" means 360°/s !) then your chances to have a stuck MC_CamIn are high.

The "funny" thing is that in case MC_CamIn is stuck, if you reduce the master's speed, it unfreezes and starts working immediately (when master crosses the next sync position) !

More precisely you have the "Busy" flag at TRUE from MC_CamIn, but you will never see any InSync flag coming (in fact slave never moves).

Additionally no error flag/IF is present. MC_CamIn instruction does not give any error.

@Siemens : it does definetly depends on Master Speed. Please fix this, otherwise we cannot do serious machines with T-CPUs. It is realyl IMPORTANT.

Affected TIA : TIA 20

This very well could be but I don't believe I am specfically seeing that. In my application it is two linear axes. I am using a 1514SP TF on V20. I wouldn't necessarily say the master is running fast. We are bending a part with a servo (Slave) relative to material travel (Master). The master is running ~150mm/s. Scan time of the PLC results in about 1-2mm of Master travel per scan. MC_CamIn is executed when Master is reset to 0mm position. The CAM profile keeps the servo at the same place until Master position ~50mm, so we are well within the bounds of the CAM profile when the MC_CamIn is executed. 

Is your CAM profile hard coded? Or are you changing it with the user program? If an adjustment is made on the HMI I use the LCamHdl_CreateCamAdvanced Siemens-built FB to recreate the CAM profile. It seems that adjusting the CAM profile between cycles causes the problem to happen more often. 

 SOLUTION FOUND.
MC_CamIn has some speed and ramps settings that cannot override the maximum ramps/speed that are set into the axis.

Solution : put a very high values for ramps in the MC_CamIn and put very high ramps values in the maximum values of the Axis's TO.

End of the story.

Davinator

 

Luuuuuuutz

 Davinator

Accidentally I stumbled upon this thread and I see that my thread is more or less similar.

Let me add one IMPORTANT thing : the chance of success ( so the MC_CamIn succesfully launches the cam and doesn't stay stuck ) is inversely proportional to Master's speed.

If master runs slow, it seems that the MasterSyncPosition is "detected" correctly and all is fine.

If master runs "fast" (and I strongly think that it depends on the CPU's performances, since in my 1511T the "Fast" means 360°/s !) then your chances to have a stuck MC_CamIn are high.

The "funny" thing is that in case MC_CamIn is stuck, if you reduce the master's speed, it unfreezes and starts working immediately (when master crosses the next sync position) !

More precisely you have the "Busy" flag at TRUE from MC_CamIn, but you will never see any InSync flag coming (in fact slave never moves).

Additionally no error flag/IF is present. MC_CamIn instruction does not give any error.

@Siemens : it does definetly depends on Master Speed. Please fix this, otherwise we cannot do serious machines with T-CPUs. It is realyl IMPORTANT.

Affected TIA : TIA 20

This very well could be but I don't believe I am specfically seeing that. In my application it is two linear axes. I am using a 1514SP TF on V20. I wouldn't necessarily say the master is running fast. We are bending a part with a servo (Slave) relative to material travel (Master). The master is running ~150mm/s. Scan time of the PLC results in about 1-2mm of Master travel per scan. MC_CamIn is executed when Master is reset to 0mm position. The CAM profile keeps the servo at the same place until Master position ~50mm, so we are well within the bounds of the CAM profile when the MC_CamIn is executed. 

Is your CAM profile hard coded? Or are you changing it with the user program? If an adjustment is made on the HMI I use the LCamHdl_CreateCamAdvanced Siemens-built FB to recreate the CAM profile. It seems that adjusting the CAM profile between cycles causes the problem to happen more often. 

 SOLUTION FOUND.
MC_CamIn has some speed and ramps settings that cannot override the maximum ramps/speed that are set into the axis.

Solution : put a very high values for ramps in the MC_CamIn and put very high ramps values in the maximum values of the Axis's TO.

End of the story.

  This was not a solution for us. I can see how for your system moving at high speeds that changing the maximum ramps would help. But this must be a different variation of the problem. 

Thanks for the answer, this should conclue the topic.

Let me add that the Preservo seems to not be essential since when you load MCCamIn, the instruction seems to be taken "at low level", thus the sync position is handled internally, not using OB1/Preservo/other timings

All,

Thanks for the input! No we have not solved this issue, and I had honestly forgotten I had made this post since it took about a month for it to take off.

I have had a feeling that we had the MC_CamIn set up incorrectly, so we are going to try changing the SyncProfileReference to 2, since we are starting our synchronization from a standstill. 

I will make sure to post a follow-up if this seems to fix my issue.