EMC: 03micges 07joints_axes3 * rc8c92e2eb771 10/src/emc/ (ini/inijoint.cc nml_intf/emc.hh task/taskintf.cc): Change function name to set joint type for clarity
micges_work: since you're in the area
what does jointSetType do?
n/m .. saw it myself
alex_joni: I'm working (locally) to allow set joint type to velocity mode (no soft limit, no ferror and such), quite easy
alex_joni: yay it's working
gooood morning!!!!! (said with greater enthusiasm than I actually feel)
what's not to like about monday morning?
because it forced me to come home from my short vacation this past weekend
in many hal components there are mixed float/double variables in computing, maybe after converting hal_float_t to double we can change all float declaration to double?
yes. without a specific reason to do otherwise, all temporaries should be declared as doubles
EMC: 03jepler 07master * r86759e826ca7 10/src/hal/components/joyhandle.comp: remove parts of documentation that correspond to autogenerated documentation
does anybody know what "source" files the nml-related code was once generated from?
by the semimythical java program
I think I remember from long ago that the emc1 makefiles would attempt to do this process
in some situations?
huh, there's a java ftp implementation in emc1
I wonder what that was fore!
the makefiles refer to an NML_CODEGEN and have some .gen input files, but I don't see the source to the code generator
emc.cc: emc.hh $(DEVP_INCLUDE_DIR)/canon.hh emc.gen
-@chmod u+w $@
-$(NML_CODEGEN) script=emc.gen display_on=false update_with_name=false;
what is $(NML_CODEGEN)?
it's never given a value
maybe it's in rcslib
cvs rlog: Logging rcslib/src/java/diagapplet/CodeGen
aha, must be
git cvsimport goes slow over the internet
jepler: the codegen thingie was iirc driven by a point&click interface
emc.gen was probably an intermediate result
twimc: I put a git import of the old emc1 rcslib online: http://git.unpy.net/view?p=rcslib.git;a=summary
EMC: 03micges 07master * rbfe1e0d6753b 10/src/hal/components/ (abs.comp counter.c freqgen.c joyhandle.comp sim_encoder.c): Change local float variables to double
micges: I glanced over that change. it looks good.
jepler: Can I add component to make conversion float->(8)bit and vice versa?
why shouldn't you?
why 8 bit? 8 bit is not a hal type
so maybe 32
conv_float_s32 - Convert a value from float to s32
conv_s32_float - Convert a value from s32 to float
alex_joni: because it's already done!
I mean float to bitmap
1xfloat in => 32xbit out
what's the use case?
if the number is big like 1e100 or small like 1e-100 what does it even mean?
so u32 instead of float
something that is "the inverse of" wsum (which happens to operate on s32) would make sense to me
at least the relationship between the value and the bit outputs is crystal clear
use case is to drive external welder that has 7 bits input
and many more
did you know classicladder already has div/mod and bit math?
a lot of kinds of math are hard in hal but easy in classicladder
it has also sum but we have sum2.comp
The math symbols are +,-,*,/,=,<,>,<=,>=,(,),^ (exponent),% (modulus),& (and),| (or),! (not).
yeah I'm not saying there should be no duplication, I'm saying CL is an easy way to accomplish this without writing new components
although, in my personal thoughts, I think we should have "all" or "no" math type components in hal... I recently wrote "which way should the carousel turn to get to pocket N faster" which would have been very tedious to do by stringing together hal components (if we even had a div/mod type component, which I don't think we do)
I don't want to dictate my way - it's just my opinion that building up math operations isn't a strength of the hal language
you end up with a bunch of things like lut5/mag3/match8/mux2/mux4/mux8/mult2/sum2 that are not really general purpose blocks
lut5 is among the components I regret putting in
I doubt anyone's ever used it
it's sure clever
so maybe cleanup ?
oh yeah, it's loads of clever
if lut5 works, and we have no way of knowing for sure that nobody's using it, there's no upside to removing it
but today I wouldn't add it
constant is quite the historical artifact
the number of people who need to drive 7-bit DACs directly from hal is probably just one or two larger than people who need arbitrary logic functions on 5 inputs..
I guess my opinion is that micges's proposed new component is probably not something widely needed, so maybe it'd be better on the contributed component wiki page or similar
another reason that we used to put in new components with a very low bar to admission (say, weighted_sum) is that we didn't have 'comp --install'
you had to put it in the one Makefile and rebuild all of emc from scratch
yeah wsum is another thing very easy to do in CL
(also many of these predate CL's integration)
I think this one predates integer math in cl
the mazak had ladder at that time, but the carousel math apparently couldn't be done without great pain
swp tried to make it generalized (since it would be installed for everyone) but that was probably wasted effort
mazak did have some odd non-binary weight, though
1 2 4 8 13
(another thing we can do now that we couldn't then is maintain our private branches forever, with our own components of particular use to us)
fwiw I'm using wsum on my lathe turret, iirc
so it's still "better than" cl for that specific task?
I would have just used ladder today...
no problem, that was only sugestion
I can add one more TODO to the list ;)
(list is already A4 ;D )
well, I'm off to examine my balls
in metric or in inches?
they are .2500 inch
well the big ones are
you mean 6.3500mm?
surely no more than 6.350
I only have inch gage blocks...
ok, agreed on 6.350
EMC: 03mshaver 07master * r563f998f4fad 10/configs/smithy/ (9 files): Update eztrol shared library version, remove unneeded ini file parameters, and improve uniformity of comments and parameters where possible for different machine types.
wait a minute, the smithy sample config doesn't work without software that's not shipped with emc2?
that's not very sensible to put in the emc2 source tree, then
oh, I see eztrol is commented out: #DISPLAY = eztrol
this is clearly wrong for a sample config, though: PROGRAM_PREFIX = /home/smithy/emc2/nc_files/
it should always be this, corrected by pickconfig when copying: PROGRAM_PREFIX = ../../nc_files/