TRAJ_SET_ACCELERATION not possible via NML ?

The main question is whether or not we can somehow control acceleration along the trajectory via gcode, which seems to be a 'no' even with 2.8. But it doesn't matter much, because controlling acceleration per Cartesian axis is possible and should be good enough for a workable solution. I would expect that testing a 45 degree diagonal move to find the limit where each large component is likely to be dropped, then setting the per-axis limit as appropriate (1/sqrt(2) of that) will be ok in practice. It just means that larger components can only be handled with about 70% of the ideal acceleration, certainly nothing I will be losing sleep over - I was just attempting to cover the requirements laid out by OpenPNP as thoroughly as they could be done, and I think that's about as far as it goes.

I have been doing more testing with pasting larger sections of gcode into my telnet client, and have found that waiting for the acceleration-setting M-code script command to fully complete before sending more commands, helps a lot to keep everything running as expected. Also waiting for the move itself to complete helps too, and is what OpenPNP will be doing anyway. Every now and then I still see a move that does not 'shortcut' the corners and instead comes to a stop between segments. I'm hoping this might just be because the RaspberryPi 3 I'm running on cannot keep up, as those occurrences are often accompanied by some lag in the remote desktop view. Will have to try on a real computer sometime and see how it goes.

Its so long ago since i was experimenting with the fastest accelleration we could achieve. I did have one stepper up to 8m/sec/sec on my plasma table.
But yes, I'm sure we observed differences between MDI and gcode in halscope. I can't remember exactly what they were. I had a feeling MDI used a slower value. 50% springs to mind. And yes agree that where a gantry is involved (so called joint axis), the slowest joint would determine performance otherwise the gantry would rack. I guess the same would apply to a diagonal move otherwise it would cause a path deviation until both axes got to speed.

I also think the radius on corners without G64 is quite a lot bigger than what is required by centrepetal accelleration. This was my interest in this but I never really explored it in detail. I did get as far as adding additional motion pins to identify if it was on an arc, the heading and what the radius was.

Just a crazy thought. I wonder if you could use external offsets to wash off some of the velocity and accelleration? It has a ratio that dedicates a percentage value of velocity and accelleration to external offsets. It might be possible to vary the offset ratio dynamically to reduce performance.... even if you don't apply an offset..

iforce2d wrote:

The main question is whether or not we can somehow control acceleration along the trajectory via gcode, which seems to be a 'no' even with 2.8. But it doesn't matter much, because controlling acceleration per Cartesian axis is possible and should be good enough for a workable solution. I would expect that testing a 45 degree diagonal move to find the limit where each large component is likely to be dropped, then setting the per-axis limit as appropriate (1/sqrt(2) of that) will be ok in practice. It just means that larger components can only be handled with about 70% of the ideal acceleration, certainly nothing I will be losing sleep over - I was just attempting to cover the requirements laid out by OpenPNP as thoroughly as they could be done, and I think that's about as far as it goes.

 

Honestly I'm not terribly concerned about optimal acceleration but I can see why you are.

This confuses me a bit:

have found that waiting for the acceleration-setting M-code script command to fully complete before sending more commands, helps a lot to keep everything running as expected. Also waiting for the move itself to complete helps too, and is what OpenPNP will be doing anyway. Every now and then I still see a move that does not 'shortcut' the corners and instead comes to a stop between segments.

OpenPnP sending command, confirm_complete, command,etc., is what I would expect for OpenPnP to do in a basic GcodeDriver setup. That implies LinuxCNC only has one segment and can't do lookahead because there is nothing to look at. You imply most of the time LinuxCNC is using the "shortcut" which I take to mean it's doing arc blending through look ahead like G64. Are you implying that LinuxCNC is sending command_complete before "exact stop"? Unless you mean it is accepting asynchronous sending which I didn't think it would support.

At best I assumed It would support multiple segment commands and blend, but aside from that I assumed it would only allow synchronized sending with an exact stop like G61.

rodw wrote:

Its so long ago since i was experimenting with the fastest accelleration we could achieve. I did have one stepper up to 8m/sec/sec on my plasma table.
But yes, I'm sure we observed differences between MDI and gcode in halscope. I can't remember exactly what they were. I had a feeling MDI used a slower value. 50% springs to mind. And yes agree that where a gantry is involved (so called joint axis), the slowest joint would determine performance otherwise the gantry would rack. I guess the same would apply to a diagonal move otherwise it would cause a path deviation until both axes got to speed.

I also think the radius on corners without G64 is quite a lot bigger than what is required by centrepetal accelleration. This was my interest in this but I never really explored it in detail. I did get as far as adding additional motion pins to identify if it was on an arc, the heading and what the radius was.

Just a crazy thought. I wonder if you could use external offsets to wash off some of the velocity and accelleration? It has a ratio that dedicates a percentage value of velocity and accelleration to external offsets. It might be possible to vary the offset ratio dynamically to reduce performance.... even if you don't apply an offset..
 

Yeah I dunno, I'm not much for tuning. If the thing works ok I use it. Honestly I'll forget 90% of what I wrote in the last reply by next week so it's good I got it down in a post.

By "segment" I am referring to the smallest individual parts of a movement, eg. in the example in my video this gcode is three segments, which are being blending by looking ahead:
    g1 z55
    g1 y75
    g1 z0

I have not used OpenPNP yet but I'm assuming it would hand off a set of such instructions to be executed as a batch, followed by a 'wait for completion'. Instructions other than 'wait' will be acknowledged immediately, and placed in the queue and acted upon, while 'wait' is only acknowledged after all other received instructions are finished. There is no need to confirm completion of every tiny piece, which would result in no blending because there would only ever be one instruction in the queue and nothing to look ahead at. And if no blending could be done I would not be here, I'd just use one of the other motion controller options.

By "acceleration-setting M-code script command" I am referring to the bash script that is called by (in my example) the M171 code. To explain it a bit more clearly perhaps, this gcode would often not result in the acceleration being applied:
    m171 p40
    g1 z55
    g1 y75
    g1 z0

But this code seems to be fine:
    m171 p40
    m400 (wait)
    g1 z55
    g1 y75
    g1 z0
    m400 (wait)

The latter 'wait' is the one OpenPNP would be doing as normal procedure. The first 'wait' is apparently required to let the new acceleration be fully applied before anything else gets into the queue and starts executing. In my server I'm thinking to insert a 'wait' automatically after each set-acceleration command, so that the client is not required to explicitly provide it. This requires that a specific M-number be used, so that my server knows to intercept it and add the 'wait'. I would have used M204 as seems to be common elsewhere, but user defined M-codes must be 100-199.

By "waiting for the move itself to complete helps" I'm using 'movement' or 'move' to describe each batch of segments handed off to be processed together. Not sure what the proper term would be. In normal OpenPNP operation there would always be a 'wait' after each movement as in my 'seems to be fine' example above, but in my earlier testing I was initially not using waits at all, and the set-acceleration commands were often not successful. I suspect this is because the set-acceleration command has no effect on look-ahead calculation, so the blending was able to carry on uninterrupted, using segments of a different move because they were already in the queue, and the new acceleration is only applied when a blend is started. The wait command forces a separation between blending sequences, and allows my segments to be grouped together in the movements I intended.

I have not used OpenPNP yet

Oh really? Me neither but I guess it's a good time to get on board.

but I'm assuming it would hand off a set of such instructions to be executed as a batch

Well that I suppose is where I was losing ya.  I expected it to either throw gcode line by line or fling them willy-nilly, maybe with the async implementation.

but in my earlier testing I was initially not using waits at all, and the set-acceleration commands were often not successful.

I do recall reading in something that acceleration, possibly other setting commands will not apply until a movement command is complete. I wouldn't expect that to be a problem with the way you're doing it or your example gcode but all the underpinnings of what LinuxCNC is a mystery sometimes.

Have you tried just applying the wait in the M171 script or does that not work?

BTW, are you doing anything with the ACTUATOR_READ_COMMAND? Which would involve reading a hal pin linked to a vacuum sensor. I'm told the Mcodes can't be read out into linuxcncrsh. But a very similar and even less tested halrmt server exists that can read hal directly. I suppose you'd be the one to know if your server implementation would have the same limits linuxcncrsh has.

Yes, the bash script could be made to wait a fixed length of time and hope the acceleration setting finishes, but it's a bit crude. During the 'wait' my server is checking LinuxCNC status values every 10 ms to catch the completed event quicker and more definitively.

For reading vacuum sensor I've made M104 return the values of motion.analog-in-00 to 03 like this. I am thinking it could also take a parameter like M104 P2 to return just one specific value:
    ok T0:0.000000 T1:0.000000 T2:0.000000 T3:0.000000
(based on reprap.org/wiki/G-code#M105:_Get_Extruder_Temperature )

So LinuxCNC would have to read the sensor and connect the input to motion.analog-in-00 etc. How this would be done I have no idea, but I presume the presence of such pins means there is a way to do it. For my own purposes I'm considering connecting an I2C vacuum sensor directly to the Raspberry Pi GPIO and read this as part of my gcode server, although not sure if that's relevant enough for other people to be including in my public source code.
 

Have you tested a method of getting an output from the motion analog pins? They're meant to be used with M66 and writing to the parameter file. I tried it breifly and couldn't get it to work. There's no mention of the analog pin values being accessible to NML from anything I've seen so I'm curious how you're handling that

As for connecting to the motion analog-in pins I can't think of why it wouldn't just be a trivial to connect the hardware driver's outpit pins to the motion pins assuming the thing reading the sensors can export hal pins. I'm working on a PCB that will use 4 ADCs to read 4 analog pressure sensors. The ADCs are SPI. The 7i92 I'll be using will have the SPI channel but LinuxCNC needs a hal component to read the function into hal pins. I'll have to bribe somebody to write me a hal component eventually but initially I just won't have vacuum sensing.

Have you just checked out the Arduino-hal projects? I don't think any of them has I2C baked in but they all have analog hal pins. I'm sure it wouldn't be too difficult to modify them to read i2c data into hal pins. At least in that case you can make a standard hal connection to the motion pins in typical Linuxcnc fashion.
 

No I haven't tested the motion.analog-in because I don't have any hardware for it, and I will probably not be using it for my PnP. I only have a router using a humble parallel port, but I have seen fancy Mesa boards festooned with various I/O which I would assume include analog input capability. It's not really in the scope of a gcode server to worry about what happens on the hardware side of the motion.analog pins.

I'm not aware of any reason why waiting for analog inputs with M66 would be necessary. The analog inputs are part of the main status info that is updated whenever you care to call it, eg. to display the machine position on a DRO twenty times a second even.
github.com/LinuxCNC/linuxcnc/blob/master...ntf/emc_nml.hh#L1223
If I understand correctly M66 is used to wait on some external condition for which the duration is not known, eg. operator input, something warming up to temperature, spindle-at-speed etc. In the case of OpenPNP wanting to know if a component was picked up successfully, I would expect it can just switch the vacuum valve and then check the vacuum pressure a fixed time later, say after 0.1 seconds or so.
 

iforce2d wrote:

No I haven't tested the motion.analog-in because I don't have any hardware for it, and I will probably not be using it for my PnP. I only have a router using a humble parallel port, but I have seen fancy Mesa boards festooned with various I/O which I would assume include analog input capability. It's not really in the scope of a gcode server to worry about what happens on the hardware side of the motion.analog pins.

I'm not aware of any reason why waiting for analog inputs with M66 would be necessary. The analog inputs are part of the main status info that is updated whenever you care to call it, eg. to display the machine position on a DRO twenty times a second even.
github.com/LinuxCNC/linuxcnc/blob/master...ntf/emc_nml.hh#L1223
If I understand correctly M66 is used to wait on some external condition for which the duration is not known, eg. operator input, something warming up to temperature, spindle-at-speed etc. In the case of OpenPNP wanting to know if a component was picked up successfully, I would expect it can just switch the vacuum valve and then check the vacuum pressure a fixed time later, say after 0.1 seconds or so.
 

"Wait on input" is just a function of M66. the analog input doesn't take the wait type argument, it defaults to immediate.

If you can grab the values off NML then that solves the problem. I haven't looked at the code, just the docs and it's not mentioned in the docs. You don't need hardware attached to test it, it's an input pin so just "setp motion.analog-in-00 5.555" and use your method of reading it, if you get back 5.555 then it's working.