The rate that G code is processed by the machine ?

Background

Trying to use junkbox steppers, and my junkbox knowledge of g code, to build a simple ( ) automata to strike XY defined points on flat surface.
'Striking' is by a solenoid, triggered briefly.

The key problem is that I want to be able to fairly precisely control the timing of the intervals between strikes.

Given that the distance moved from one position to the next will vary, there will be a small variation in the timing of the strikes.

Is it possible to control the speed of execution of each line, either so that it is constant, or so that it might be varied in a controlled manner ?

Yes, it's music.

Most grateful for any input, but please don't ask me to learn a new language.

John

Hi JT,
Yes, I was going to use either Z axis or more simply one of your suggestions for the solenoid.
Z might be the best, as it would enable the speed to be varied giving different dynamics to the strike - high speed = loud.

Old grey cells stumbled into action over lunch, and I remembered 'Dwell', so a G4 between each G1, with P being calculated from the difference in the spatial distances moved and F rate each time wouldn't be too problematic.
There would only be a finite numer of calculations to do, and I guess some sort of 'look up table' from a spread sheet could be used.

Perhaps now is the time to confes to an idea I've had for many years, and, being in a bit of a bad place at the moment, I need a dstraction.
I've long had a delight in the creative wizardry of builders of automata, and over the last few weeks an idea has come into focus.

While still struggling to learn to play the hammer dulcimer alongside several cnc projects that are ongoing, I thought it would be some sort of tying together of several threads in my life if I were to build a h.d. playing automata. Not in the grandiose style of the 18th century, but more the 21st.

Someone(? thing) to duet with as I learnt.

A recent experience of discovering Pat Metheny's Orchestrion Project, where he uses multiple solenoids to create a wonderful effect from standard or specially created instruments was my final undoing.

A pair of arms, each driven by two steppers for the xy positioning, plus a triggered striking mechanism that might hit soft, medium or hard on about 36 sets of strings is my target.

That's it, in a nut shell, and perhaps I'm the nut, but it will keep the grey cells going.
John
Ps another post about the timing problem will follow.

The problem of timing is one of being able to get the strikes to occur on the beat, if the time to make the traversing movement is a variable, and the striking is done automatically at the end of each movement.

If I use a third stepper (Z axis) I have a way of controlling the soft/medium/hard dynamic for the striker, by way of the feed speed, and the timing moves to a separate line of code, but at the expense of another stepper et al., plus twice as many lines of code, and more if I use a G4 'dwell' to equalize the timing.
If I use a two state o/p to control the striker, attractive in reducing expense and code, but sacrifices dynamic control. Perhaps this is a small loss till something turns up !
An additional atribute that would be desirable would be to be able vary the speed in real time, in the way that Axis allows.
I think a completely separate issue, but one to bear in mind.

Early days yet, but these are the first steps in identifying some of the hurdles.
The electronics, engineering, and musical instrument I will cope with, but only if I get a clear picture of how this thing will work !!

Never used inverse time mode and need to understand it .
Post again when I do.
J

John, I think you've given me the answer.
If each of the transverse moves are all completed in the same time, the 'striking movement will be of only a very small variable.
If it does alter the rythmn, then an adjustment of the F word in the next line could be automaticaly inserted as a parameter that relates to the dynamic of the previous one, the cause of any variation.
Hope that makes sense.
J