The rate that G code is processed by the machine ?

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

Makes sense to me.

JT

So six days thinking about the task I've set myself.
Not sure if I should start a new thread, but I'll continue here untill someone suggests otherwise.

I've looked at the layout of the h.dulcimer and the 'map' of where the hammer actually hits the strings, and it now looks like a simpler approach would be to use three linear axis, each with a hammer solenoid doing the striking.
There would be only 12 striking positions for each axis , each roughly 1.5 inches apart over a 16" track.
Each note woud have a unique X, Y, or Z value, and using an inverse feed rate, I can control the rthymn. I'd use the various other available controls to fire the hammers.

At the moment, I'm going with Axis and G-code because they are familiar to me, and configuring a new m/c shouldn't be too onerous.

However, further down the line I can see a possible difficulty. I currently use 8.04 on a desktop in the workshop(best latency), and I feel reasonably confident that the junk boxes in the workshop will provide me with a working prototype.
But if I want to get out onto the street with this thing, a laptop plus car battery power supply looks like a necessity.

Will this be doable, or should I, at this early stage, go in a different direction to find an equivalent solution ?
Arduino ? Raspberry Pi ? BeagleBoard Black ? or ?

John

If you have a finite number of moves, I'm thinking you could take an old "machine-language approach" and "tune your code" by timing each of the finite moves and storing the results in a table (of #<_named_parameters>) which can then be used to calculate another table of "Perfect" feed rates for each move.