Binary encoder - Sauter SK-501 turret - Strobe diagram of functions

I have a sauter SK-501 turret.
I managed to find the function diagram, see below.

 
 

My questions are as follows:

- I haven't been able to find much about how the strobe pin works. What is it used for in an encoder?

-The diagram shows that the strobe signal is used to continue the tool change procedure.
Does courousel9.comp manage this on its own (does it have a signal out that I can use?), or do I need to use carousel.N.strobe to count the number of falling edges between my current tool and my next tool in my HAL file?

 

A strobe signal is normally used to indicate that the
other signals are valid (so should be latched/captured)

The strobe pin serves to indicate that the position of each tool is valid, this pin on the carousel enables the carousel pin. ready and serves, for example, to stop the rotation of the motor. The pin of the pre index control proximity sensor is used to activate the pre index solenoid, which must be activated when the pre index sensor signal is activated. I don't know what the exact model of your turret is. I have a TOE 100 turret that is very similar to yours. The diagram that I publish is blurry and cannot be seen well.

thank you for your explanation, I understand the stobe signal better.
I have just compared the diagram of the TOE 100 turret with my turret and it is indeed the same (except for certain delays).

Would it be possible for you to share your M6 remap HAL files with me?

I still don't understand the signals managed by carousel9 and the M6 remap.

 

what happens to the pre-indexing and locking proximity signals?

  - schematic simplification?
  - managed by carousel9?
  - other?
 

If you use the carousel component you do not require remap M6. What card are you going to use to control your turret? The good thing about this component is that you can control its turret without much complication, my TOE 100 turret was more complicated to control because it needs to reverse the direction of rotation to lock the tool changing disc and this is not very well implemented when it comes to use it bidirectionally. From what little I have read, your tool changer disc is blocked by the solenoid. what happens to the pre-indexing and locking proximity signals? These signals serve the carousel component to control its operation, for example the locking output is used to control the activation of the turret motor, it will only be activated when the state of this signal is zero. You may be wondering how to control this solenoid, simple, carousel has an output pin called carousel.0.enable, this output is activated when a tool change instruction is given in the G code, for example M6 T1 G43, once this signal is activated is used to deactivate the solenoid and it unlocks the disc and the lock sensor is changed to zero, and this deactivation signal is used to activate the engine with the signals carousel.N.motor-fwd or carousel.N. engine-rev, depending on which is the shortest route for this change, that is determined by the same component. Once the disk begins to rotate, the encoder inputs will indicate to carousel when the selected tool reaches the position and is confirmed with the strobe, this causes the carousel.N.ready pin to be activated indicating that the selected tool is in position, and with this signal the motor is deactivated and in turn activates the solenoid to re-lock the tool changer disc. The pre index signal is used to indicate that the tool disc is reaching a valid position that allows the effective tool to lock it. Regarding my configuration, I will send it to you tomorrow. If you could tell me what input and output pins you will have available for control, I can help you make a configuration. Another question: do you have the contactors to activate the motor in both directions?

 

 I think I'm wrong, yesterday reading your turret manual carefully I thought that it works the same as the TOE100, the difference apparently is that yours does not have a brake. I sent you my configuration, the difference is that your encoder has an additional output for the parity bit, mine does not have it because they changed the encoder for one with a gray output.

change loadrt carousel pockets=6 encoding=binary num_sense=4 dir=1

 

thank you for your hal, yes I confirm the diagrams of our two turret are identical.
here is the diagram of my turret in better quality to avoid hurting your eyes

 

red : motor
green . solenoid
purpel : pre-indexing control
yellow : locking control
blue . strobe

i will check your hal and i come back to you for sure some questions !

after reading the hal file, i have a few questions.

why use a gray encoder when your code table encoder is binary?

you activate the solenoid when the selected tool is in activate position whereas the schematics show that the solenoid activates at the last falling edge before the selected tool. is it too complicated to program this? or is your solution sufficient?

you only have one direction of rotation, is it too complicated to use mux to manage reverse directions of rotation to block the turret?

 

I used gray code, because the turret I have is used and did not have the original encoder and that is why I manufactured my own encoder and I did it with gray which has the advantage of not needing a parity bit to verify the correct reading of the position as if A binary encoder needs it. The tool holder disc is locked internally with a disc with "nails", this disc retracts when the motor begins to rotate, releasing the tool holder disc and it begins to rotate, when the desired position is reached the preindex sensor is activated, This causes the solenoid to activate and it locks this disc with nails and in turn, reversing the direction of the motor causes this locking disc to move forward and so on. Lock the tool holder disc. Regarding using the bidirectional rotation, I have not tried it, unfortunately the carousel component only reverses the rotation of the motor automatically when the motor rotates forward, but when it rotates backwards, it does not reverse the rotation automatically, that is why I do not do it. I was able to implement, and the truth is I have not found how to save the initial direction of the rotation, to determine which way the motor should rotate later. In another thread I wrote to Andy, who was the one who created that component, to see if he could help me with the bidirectional solution, but I didn't get a response.