On Saturday 30 April 2016 05:56:10 andy pugh wrote: > On 30 April 2016 at 05:16, Danny Miller <dan...@austin.rr.com> wrote: > > http://www.machsupport.com/forum/index.php?topic=27782.15;wap2 > > > > Looks like they're saying M62 actuall takes effect slightly before > > the G-code command executes, which could be a problem. > > That's Mach :-) > > LinuxCNC turns on the output and starts the associated move at the > same time. > > However, for rastering you really want to be moving at constant speed > and "clock out" the image data depending on position.
This might be doable with halstreamer and streamer, and might be used with a base-thread clocking rate. The man pages do not indicate there would be a line length limit other than the size of the shared memory. Would that offer fine enough detail, switching the laser on and off in base-thread time slices? I can see that since the data would best be described as random, that it would need to be fetched in bit counts that would represent one full line scan per line since there would not be a unique EOL character to such data. The laser would need to be turned off by the fifo empty, motion paused or moved to the next line while the fifo is being reloaded from the file as that would take an arbitrary amount of time. Details of the startup acceleration I see as a positioning problem because you would want the laser carrier moving at full speed and at the true starting position of the image when the first bit was clocked out. The inclusion of the enable bit mentioned in the man page for streamer would make some of the other timing requirements much easier to meet. To work in both directions would be desirable as a retrace move would be a huge time waster, but inverting the order of the fifo clockout as opposed to pre-ordering as the data file was being generated seems like the better idea. I can sure see a lot of cpu being used during the fifo reloading time at the end of each scanned line to accomplish this. If clockout from whichever end of the fifo is needed, it seems the direction bit of the axis doing the scanning might be usable for that. Details TBD of course. Size of the scanned image and its scaling to fit the image being cut would have to be preprocessor problems as any change in the size and scaling would require the source file to be regenerated. I could also see the potential for 3D by clocking out a byte at a time which controlled the lasers power for that base-thread slice of time. The files size would of course be 8x the size of an on-off bitfile. That might, from available memory limits, constrain the size of the image being constructed as I can't imagine a mid line reload without artifacts in the image. Food for the concept at least, I'll get me coat. :) Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
