Back
[13:37:13] <threeseas> any life here?
[13:55:33] <alex_joni> only a little ;)
[13:59:06] <alex_joni> threeseas: I'm afraid that answering your question involves some people who actually have seen the rs274d standard
[13:59:19] <alex_joni> not sure any of those are around here
[13:59:39] <alex_joni> on the other hand, I remember that rs274ngc was created exactly to fill the gap where the standard is unclear
[14:00:05] <alex_joni> not everything is specifies in the standard, so machine manufacturers started to go their own ways and still fit the standard
[14:03:43] <threeseas> ok. My objective is to see if I can use emc as a testor for g-code generated by another software package,
[14:04:08] <alex_joni> usually the CAM software you talk about has lots of postprocessors
[14:04:13] <alex_joni> for different dialects
[14:04:36] <alex_joni> but if you know how exactly the output needs to look like, you can probably use the interpreter in emc to test the code
[14:05:10] <alex_joni> you would probably have to tweak it a bit to fit your particular dialect
[14:05:22] <alex_joni> re: big routers, I know only these two:
http://www.lmwatts.com/cnc.html
[14:05:47] <threeseas> yeah but its my understanding that I have a postprocessor that can generate rs274d complaint g-code and we are getting another machine from onsrud that is supposed t o be ablet to use this standard
[14:06:23] <alex_joni> http://users.pandora.be/engineering/index_files/page0001.html
[14:06:37] <alex_joni> the rs274d is incomplete at best
[14:07:12] <alex_joni> I think that counts as a large router..
[14:08:49] <threeseas> I believe we are getting one in this serire
http://www.cronsrud.com/super_duty_c.html
[14:09:55] <threeseas> I guess the question is: does the rs724d standard fit within the rs274ngc standard?
[14:10:11] <alex_joni> yes
[14:10:25] <alex_joni> but so does it fit into the fanuc dialect, or mazak or whatever
[14:10:54] <alex_joni> otoh, I'm not an RS274 expert by far
[14:11:11] <alex_joni> I really advise you to maybe try to send an email to the emc-users list
[14:12:41] <threeseas> I'll generate some g-code thru that post and try it on emc sim.
[14:15:36] <threeseas> the problem I have run into is that c.r.onsrud claims cim-tech won't write a proper postprocessor for onsrud machines. For use thru router-cim (cim-tech is owned by Komo - a router hardware manufacture and competitor to other such machine makers)
[14:17:18] <threeseas> We are using an old komo and adding a c.r.onsrud machine. So I know router-cim. but c.r.onsrud recommends any cad/cam package that is made by companies that don't make hardware.
[14:18:13] <threeseas> yet they claim their high speed machining option is able to use iso standard g-code.
[14:18:26] <threeseas> so the question is: who is lying?
[14:18:40] <alex_joni> no-one
[14:19:13] <alex_joni> actually if you have a CAM app, I suspect you can write your own post-processor the way you like it
[14:19:21] <alex_joni> at least that's how I seen is done on most apps
[14:19:38] <threeseas> cim-techs claim of having an iso rs274d complaint post or c.r.onsrud claiming cim-tech doesn't make a proper iso standard post?
[14:20:05] <alex_joni> they probably are both rs274d proper
[14:20:07] <alex_joni> BUT
[14:20:19] <alex_joni> the rs274d only defines a subpart of modern G-code programs
[14:20:29] <threeseas> I don't know anything about writting a post processor
[14:20:41] <alex_joni> each machine manufacturer has a couple of custom g-codes which they added
[14:20:55] <alex_joni> but that doesn't mean the machine is not standard by rs274d
[14:21:04] <alex_joni> because the rs274d is really vague about a lot of things
[14:21:12] <alex_joni> so different things still fit the standard
[14:21:51] <alex_joni> so, the real answer is: rs274d code produced by a CAM app, can sometimes not work on a rs274d machine
[14:22:07] <alex_joni> it's just like with languages..
[14:22:13] <alex_joni> take german for example
[14:22:19] <threeseas> so its not really a standard then
[14:22:31] <alex_joni> it is a standard (has been for the last 30 years)
[14:22:36] <alex_joni> but it doesn't define ALL aspects
[14:22:46] <alex_joni> which makes dialects possible
[14:22:50] <alex_joni> and incompatible
[14:22:55] <threeseas> then who is to claim what is "proper"
[14:23:02] <alex_joni> no-one can
[14:23:12] <threeseas> so it is onsrud lying then
[14:23:22] <alex_joni> they probably all want to sell their own machines and software
[14:23:24] <threeseas> its sales hype
[14:23:28] <alex_joni> indeed
[14:23:33] <alex_joni> BUT
[14:23:52] <alex_joni> each CAM app has a postprocessor, which translates the instructions the app has generated to the g-code
[14:24:05] <alex_joni> say one machine uses G73 for dwell, another G74
[14:24:12] <threeseas> onsrud doesn't mk cam software but cim-tech is the only commercial grade package that is owned by a hardware maker (komo)
[14:24:25] <alex_joni> the 2 different postprocessors will each know what g-code to output when there is a dwell in the program
[14:25:20] <alex_joni> I am sorry, I am not familiar with "cim-tech" nor "onsrud"
[14:26:25] <threeseas> onsrud is a manufacture of router bits - c.r.onsrud makes cnc routers and they are connected.
[14:26:39] <threeseas> Cim-Tech is really better known as Komo
[14:27:25] <threeseas> http://www.komo.com/
[14:28:18] <alex_joni> threeseas: gotta run, sorry
[14:28:24] <alex_joni> I'll be back later
[14:28:43] <alex_joni> but there probably are people on the users list that know more about standards and what is normal in the CNC business than me
[14:28:54] <threeseas> thanks
[16:53:59] <alex_joni> hi jeff
[16:55:20] <jepler> hi alex
[16:56:00] <alex_joni> what's verbatiminput ?
[16:56:42] <alex_joni> some lyx way of including files?
[16:57:18] <jepler> yes
[16:57:30] <jepler> if you want to include a text file in a typewriter font
[16:57:38] <alex_joni> I see
[20:45:06] <alex_joni> jepler: another small question on tkemc :(
[20:45:29] <alex_joni> you know how the display with the values of the sliders have a gray background?
[20:45:35] <alex_joni> I wonder where that comes from
[20:46:09] <jepler> *top*controls*oride*top*value*background: gray
[20:46:12] <jepler> the file TkEmc, I bet
[20:47:17] <alex_joni> thanks
[23:11:05] <jmkasunich> jepler: you around?
[23:14:53] <jmkasunich> I'm a little confused by the first example of comp, section 8.7.1 in the hal manual
[23:15:12] <jmkasunich> the text says: This component functions like the one in ’blocks’, including the default value of 1.0. It illustrates
[23:15:12] <jmkasunich> the use of extra_setup, without which the default would be 0.
[23:15:37] <jmkasunich> but as far as I can tell, the param is inited by
[23:15:57] <jmkasunich> param value float r = 1.0;
[23:16:10] <jmkasunich> and there appears to be no extra setup function
[23:25:05] <jepler> hm maybe I screwed up the docs
[23:25:31] <jepler> I added 'param ... =' today
[23:25:45] <jepler> but didn't update the proser
[23:25:47] <jepler> prose
[23:25:50] <jepler> I'll fix it later
[23:26:08] <jmkasunich> ok
[23:26:23] <jepler> does 'param ... =' make sense to you?
[23:26:30] <jmkasunich> oh, I think I understand - the original version of the example _did_ use the function to set the param
[23:26:33] <jmkasunich> yes
[23:26:47] <jepler> I think it's the thing you'd most frequently do with extra_setup so I made it possible without it
[23:26:53] <jmkasunich> good
[23:27:29] <jepler> by the way, there are some reasons I think we should keep parameters
[23:27:47] <jmkasunich> the only difference I see between the "blocks" ddt and the "comp" one is the name of the update function
[23:27:56] <jmkasunich> blocks calls it ddt.<num>
[23:28:06] <jepler> basically it boils down to this: you can make per-instance data (that is not an array) into parameters
[23:28:07] <jmkasunich> comp calls it ddt.<num>.update
[23:28:09] <jepler> and inspect them at runtime
[23:28:28] <jepler> with no runtime performance decrease .. just the overhead of the HAL structures
[23:29:00] <jmkasunich> making them pins instead adds one indirection
[23:29:28] <jepler> hm -- so maybe I need a way to declare a function whose name is exactly the instance name..
[23:30:21] <jepler> if you used 'function _;' you'd get a function 'ddt.<num>.', I think .. maybe that could be extended to remove the "." too, not just the trailing -/_
[23:31:07] <jepler> what do you think? It feels cryptic
[23:31:24] <jmkasunich> yeah, but cryptic is ~ ok if documented
[23:33:00] <jepler> I just realized you can also get a pin and a param that have the same hal name -- pin foo; param foo_; -- but I don't think I'll explicitly document that
[23:33:18] <jepler> hmm, you can also write pin foo; pin foo_; and get a component that will always fail to register
[23:33:19] <jmkasunich> my general tendency now is to make all components that have only one function use the "block.num" function naming convention
[23:33:28] <jmkasunich> heh
[23:34:09] <jmkasunich> on a number of the early componets I used "block.num.something", and I think all it does is add typing
[23:34:37] <jepler> OK, I'll implement the special behavior for 'function _' -- should I make 'pin _' or 'param _' work that way too?
[23:35:10] <jmkasunich> by "special behavior" are you talking about removing the trailing '.' ?
[23:35:21] <jepler> yes
[23:35:34] <jmkasunich> seems to be a generically good thing
[23:35:41] <jmkasunich> I don't think any name should end it a dot
[23:36:01] <jepler> I am trying to think of a case where you'd want to have a pin 'example.0' .. maybe 'constant.0'?
[23:36:24] <jmkasunich> there are two separate things here
[23:36:31] <jmkasunich> one is to allow "_" by itself
[23:36:40] <jmkasunich> the other is to strip trailing dots
[23:37:09] <jmkasunich> strip trailing dots seems reasonable for all names
[23:37:21] <jmkasunich> "_" by itself _might_ only make sense for functions
[23:38:38] <jmkasunich> btw, the "constant" block, like the very old "supply" component, are both kind of useless
[23:39:29] <jmkasunich> instead of making a signal and then hooking a constant block to it to set the value, I can just make the signal and do a sets to set the value
[23:40:01] <jmkasunich> which brings us back to the signal vs. parameter devate
[23:40:03] <jmkasunich> debate