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