|
|
Last edited by 71taa In 2019-3-15 10:24 Editor
It's only my opinion, maybe the topic starter has more specific requirements.
1. The scanning G-code is being formed by users. It's up to them to define the scanning strategy, speeds, etc - in a standard G-code way
2. In the place users like to capture the coordinates, they place the call to the 'scanning macro', which works similar to probing macro (moves down, senses the probe, stops, falls back off). The coordinates of the touch point should be captured. In case if coordinates are being stored in some internal variable - we even could use standard probing macros for this stage.
In order to not overengineer things here we could assume that scanning macro always works only with Z coordinate. It's fine for majority of CNC schemes and typical appliances like levelling over uneven surfaces. Also (as we already have 3 modes of probing, and one of them is a 'custom' one)
we can use probing functionality itself, yet you have a better view of the controller capabilities and limitations.
3. Then coordinates should be stored sequentially into the file. If we have them in some variable - it could be separate call to "coordinate saving" macro. In case if we have integrated 'scanning macro' - as a part of its call
4. The format of coordinate storage in the file isn't that important, it's good to have all 4 coordinates (maybe someone needs only 3) and some delimiter between them. E.g.:
102.131;14.145;16.14;35.5
112.131;14.145;16.14;35.5
5. Why the format isn't that important comparing to the data itself? Because different external software have their own requirements and it's impossible to meet them all. So it's more efficient to post-process generated data with simplest software converter then define a lot of configuring options to the controller.
6. It's near all, except the file handling. Again we need to be minimalistic here, as a complex file handling could bring a lot of setting options, and instead of flexibility users can face difficulties.
6.1 Here we need the file definition itself (name and location). At the very minimum it could be hardcoded (in the controller) location and name on the external drive and won't be configurable by users. At maximum it could be a parameter of the macro if the controller script processing capabilities allows that. And anyting in between (like configurable location via controller settings, etc).
6.2 Probably it's good to have another macro "start/init scanning" that clears the file in the (defined) location as a preparation for a new cycle. It could be placed by users in their scanning code to form self-contaned scanning code. It will increase usabilitiy of the solution, less errors with uncontrollable growth of the file
6.3 And the last, but not least - the limitations of this solution. In case if we have some hardware limitations (size of the file, number of stored coordinates, etc) - either include them in the description and/or check limits internally, stopping capturing the coordinates as the limit is reached.
For me personally single macro for incremental writing of current coodinates on call is enough (without probing subsequence, etc). As I've tried to use HID emulating controller for simple automation and it's rather convenient (though not that reliable, as I have no feedback from the controller of course). So it will be an external control of manual DDCSV movements in step mode via "keyboard" commands (it could be done via MPG port as well), external touch probe hit detection, call to the "store coordinates" macro via extkey macro call followed by the external switching of the key2, etc. But that's clearly not a standard use 
|
|
Posted at 2019-3-14 11:31:55