I can fix the indenting on hal_lib.c I'm not opposed to separate changes however I did use the pyhal.py to create tests for testing hal_port code. pyhal.py is not actually required for hal_port to function. (Assuming hal_port functions properly)
The halcompile.g doesn't strictly become a requirement until someone wants to generate a .comp using hal_ports. I can't say if pyhal.py should replace halmodule.cc. My first approach was to try to modify halmodule.cc but it was quite difficult to wrap my head around which is why I wrote pyhal.py. pyhal.py could potentially replace halmocdule.cc but I don't know exactly how that would effect existing components. Is there a performance penalty? Can everything that halmodule.cc do be done with pyhal.py? I don't know yet. The remapping of M codes are part of a sample config only. It is an example to show how I integrated the raster programmer component with the raster realtime component. There are I'm sure many other ways to do this. Right now the raster component is a software only version. My actual laser machine has mesa hardware so I ultimately want to use datapainter instead of the raster component. I'm sure that the ultimate driver for datapainter will work in much the same fashion and share some code with the software raster implementation. It may be easier to understand if we did this as 2 separate commits. hal changes halcompile.g hal_port tests pyhal.py then laserpower.comp raster.comp rasterprogrammer.py raster tests as well as the sample config On Tue, Aug 6, 2019 at 8:35 AM andy pugh <bodge...@gmail.com> wrote: > My opinion only: (I am not sure who has the final say on what goes in to > Master) > > On Mon, 5 Aug 2019 at 15:38, Curtis Dutton <curtd...@gmail.com> wrote: > > A HAL_PORT pin allows for a writer component to send many bytes in one > > operation to a reader component in real time. The PORT pins behave just > > like any other pin in HAL and can be linked, unlinked etc... > > > > In addition to the modifications to make hal ports some other > modifications > > and new parts were required. > > > > halcompile.g - added port type. Also added (pin,param,variable)_ptr > macros > > to allow access to the actual pointer to those values. > > > I think that these should go in together, as two commits in the same pull > request. > > pyhal.py - similar to the other python component pyhal.py uses the ctypes > > python library to interface with hal, which is significantly less code > than > > the halmodule.cc python wrapper that currently exists. > > > > Is this necessary for the hal_port code to work? Is this a replacement for > halmodule.cc or do we end up with both? > I think that, unless it is an integral part of your hal_port, this should > be a separate pull request and discussion. > > laserpower.comp - allows vector control of a laser, scaling power during a > > move and has no limitations of number of joints a machine can have. > > > > raster.comp along with a python raster.py programming module to control > the > > raster, this allows control of the raster component from user space. > > > > Standalone .comps should be no problem, I would roll these in with the main > pull request, along with the tests. > > remapping of M codes to control the raster.py raster programming component. > > > is this part of the sample configs? Or are you saying that you have made > more M-codes remappable? > > Is this an enabler for, or an alternative to, the Mesa "datapainter"? > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is designed > for the especial use of mechanical geniuses, daredevils and lunatics." > — George Fitch, Atlanta Constitution Newspaper, 1916 > > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
