the end of the last pass of the smp one looks different, but it looks like it is literally the last pass -- vel goes to 0 and stays there
(that's the only difference I spot, a more pronounced "V" in the velocity profile at the end)
it's the beginning of the sync that bothers me
notice how on the vanilla, they are all the same
maybe I'm confused about where the synchronized move begins
is the thing in major divs 7 and 8 a synchronized move?
and what's in 3 and 6 is returning to the starting point?
if so, that's the thing I thought was different too, but my understanding of what part was the synchronized move was wrong
in the cyan above the number 11 button is the downward point I think is wrong
yes 3,6 is returning, rapid unsynced
yeah the end of the last pass is an abort or the end of the program
beginning of the last pass is the odd one
if we had more here, I think we'd see 1/3 or so wrong, which is what it seemed like he has always had
that's not exactly rapid
err, yes it is
* SWPadnos should line up the images better
looks like about 15/sec
yeah - somehow I was associating the slow negative vel with the return movement
rather than the fast positive
no, that's the synced move
and presumably the little bump near the end of the synced move is due to an angled exit?
yes it loses position a bit because of the corner
if you make the angled exit longer, you see it catch right back up (I did that in one of the ones I sent to the list)
it seems like it could be better, but it really doesn't matter much
I played with hm2 probing some more but I remain unenlightened
wooo, what luxury it is to be able to use cutter comp on the mill, and have it be smart and predictable and actually work right
Newb compile question.. I did a git clone to a local directory emc-dev as per the example in the online manual
So now I have clone of the online repository on my PC. I do an apt-get remove to remove my existing CD install of Hardy Heron EMC2.
I run the compile and end up with EMC2 compiled code in the emc-dev directory. This doesn't seem quite right. I can run the software - by changing the desktop shortcut to point to the
new emc starting script location and it loads the profile that I configured before no problem. But what it I want to compile a different branch of the repository. If I recompile the way I am currently setup
I will overwrite the files I just compiled. How can I set this put so I can multiple versions of EMC2 loaded at the same time - like a master, and a branch etc. I thought I could do a git pull from my local repository to another directory and then compile there but that didn't seem to work. Sorry for writing this book on the IRC!
I asked this same question on the email forum - so ignore one of them! :-)
Correction > How can I set this put >> How can I set this up....
compiling in the git clone is the usual way to work. if you want another branch in another directory, just get another clone
I think you are right that you can do that by cloning your own clone, but you could also just download another one.
there's probably some clever way of making a "cheap" local copy, but I'm not clever enough to know it
Dave911, to use multiple copies, you need to be sure to configure with --enable-run-in-place, and when you want to use one version or another, you need to source the scripts/emc-environment script from the correct directory
Dave911, you can use the --depth option with git clone to get only recent history for a faster download or a "cheap" local copy.
I don't follow you ..... right now I did a clone and then I set it to use the master and then I did a compile... I did not set a enable-run-in-place but I saw through the compile process that it automatically set that for me.. (surprise!) If I wanted to compile a branch wouldn't I just use Git to set to the branch and then compile? -- depth option - I need to look that up..
Git is a very interesting tool
note the comparison chart
you can also use -l for a local copy, and -s for a shared copy
see the examples at the bottom of the man page for git-clone
the B model may also work for you, though the K is faster
I think I read through most of the online Git book and I tried to do a pull off the local clone of the repository and that didn't work.. I thought it should have... perhaps I am making this too difficult...
>>-1 for local copy and -s for shared copy ......... ok I think I have more to read! :-) To make this simple, is the suggestion to just do a clone of what you want to a unique directory and then do a run in place?? Simple is good..
run-in-place is required. how you get multiple versions of the source is up to you
>>run-in-place is required Do you know what exactly is run-in-place is ?? I tried to find some definition of that but I must have missed it. I tried without it and it set it anyway...
it means emc2 is not installed system wide, but can be run from the directory where it is compiled
which is necessary if you want to be able to switch between different versions, unless you want to install them over each other every time you want to change
OK, that is what I was thinking it was. So when I ran the live CD and installed it on my PC, was that a system wide install vs a local (run in place) installs ---- or are all EMC2 installs - local installs?
SWPadnos: I guess you could have one version installed for normal use and the others run-in-place?
Dave911, the CD installs the entire operating system, the realtime kernel, and a certain version of EMC2
Dave911: that would be system wide. emc2 was installed in /usr/bin and other main directories
that installed version is managed by the package manager, and can be updated only when a new release is made
and it is systemwide
with run-in-place nothing is outside of the directory tree where you compiled emc2 - eg. emc-dev or whatever you called it.
if you want to run different versions of EMC2, you need to compile them, but you don't want to install them systemwide, since the files will overwrite the ones from the systemwide installation
(dunno if that made sense - still digesting coffee :) )
heh, time for another cup here! see you later.
so to have "side-by-side" versions on your system, you need to compile them such that they can run from the place they're compiled, hence "run in place"
Oh... so the big difference is whether or not the package manager manages the installs or not??
(note that you can only run one instance of EMC2 at a time)
yes, more or less
nothing you compile will be managed by the package manager, but if you "make install" a locally compiled version, it will install files into the same places as the packaged version
so they stomp on each other, and you'll still have only one version usable at a time
but that gets confusing, because the package manager still thinks that version x.y.z is installed, but when you run EMC2, you may see version p.q.r running, since "make install" overwrites the actual executable files
but doesn't mess with the package database
OK... I get that ....
Right now I am doing:
sudo make setuid
So if I wanted to do a system install I would do: sudo make install ??
if you configure without --enable-run-in-place, then you shouldn't be able to run the version you compiled
unless you make install
if you use --enable-run-in-place, then you must make setuid, then source scripts/emc-environment
that source (or ".") statement must be run in every shell you wish to use the RIP (run-in-place) version
I deliberately left out the --enable-run-in-place and the compile turned it back on by itself and I can run the "master" version... ??
I didn't know about "make install"
What I did last night was to do the run in place - since it turned it on anyway. It all compiled into the source directory - and I just modified the desktop launcher/shortcut to point to the new "emc" location and I left the tail end of the command the same (in the shortcut/launcher) so it loaded up the proper INI file for my config.
Does this make sense??
it *is* OK to run the emc command from a run-in-place install without doing the ". scripts/emc-environment" first. It is the only exception.
If you want to e.g., open up a terminal and run halscope from it, then you have to ". scripts/emc-environment"
oh. is that a (relatively) new change?
Sorry..... What I ended up with last night from what you guys have told me is a run-in-place install that is running out of the emc2-dev/src directory. The emc2-dev directory was the target location on my pc for the git clone.
In order to make this work. I went to the shortcut that was on desktop already (from the live cd install and machine configure) and I went into the properties and I put a prefix in front of the command line so it would go to the \emc2-dev\src directory to find the emc script file and start to run emc2
so the command line in the launcher looks something like \home\emc2-dev\src\emc \desktop\ \ \ \__.ini etc
SWPadnos: no, it's been that way for quite some time
huh. I thought there were path issues for things like halcmd and modules
but if it works now, great!
SWPadnos: if you're aware of problems, let me know about them
ok. I thought it was a "feature" before :)
the only problem I've seen is CL saves its file in the cwd, not the config dir
the only time I do the . scripts/emc.... is when I want to tinker with hal. Otherwise I don't bother for normal running.
incidentally, I was useing haltcl + tclreadline last night trying to figure out the hostmot2 encoder latch thing
If I just keep using the shortcut on the desktop to get to my config files including the custom.hal file etc, I should still be ok to run the scope tools shouldn't I???
it is pretty nice -- I could define a tcl procedure to strobe a pin and another to read the encoder control register and parse each bit
Dave911: from the emc menus - should work (I think)
jepler: still getting random data?
skunkworks: OK, thanks
I'm sad my spare m5i20 got used in Jr...
skunkworks_: my test setup must be wrong -- I was getting no latches
[14:39:41] <jepler> http://pastebin.ca/1647825
if you guys need a 5i20 to test - I have a spare that I don't see getting used for a while...
oh, a different wrong than we had before?
don't the flags get reset every servo cycle?
(assuming they're read in the servo thread)
skunkworks_: thanks, but jepler already has one and I'm not smart enough to work on the driver
As usual - you guys are awesome!! - I really appreciate the help. I don't think I could have figured this out without your assistance...
SWPadnos: in my testing I was looking for two things: for LatchOnProbe to be cleared (what this test did primarily) but also for the (new) hal signal rawlatch to be updated with a nonzero value
I haven't looked at the 5i20 code recently - do you know if reading the flags register automatically clears the flags?
it may be true that write is setting LatchOnProbe true every cycle (I think it's not; there's code to write the encoder control registers only when the desired value is different from the last written (read?) value) but it should still be getting a new rawlatch
SWPadnos: wow, the normal opto22 are 5ms? that's much worse than I thought
SWPadnos: no, as far as I can tell from the firmware source the act of reading the ccr doesn't change the ccr
ok. then again, even if it's not automatic, the index handling code would presumably run before the "raw read" code, so the flags would have been cleared by the time you see them
cradek: I did realize one thing that could cause repeated spurious probes, though-- switching probe polarity makes it look like there's an edge
I don't follow
cradek: as I interpret the vhdl, the way probe polarity is done is by inverting the input to the noise filter (probesrc). the output of the noise filter is used to detect a rising edge.
so suppose probe = '0' and probepol = '1' (active high) initially. The output of the noise filter will be '0' and no edge will be detected.
Now set probepol = '0'. The input to the noise filter will change from '0' to '1', and 3 or 15 cycles later the output from the noise filter will change to '1', giving a rising edge of the probe signal
you effectively have two probe inputs which are XORed together. one is hardware, the other controlled by software
ok, I get it, thanks
I think that the way I wrote the driver we actually were testing on jr I wrote probepol='0' most of the time, and probepol='1' at the same time as I wrote latchonprobe='1'
it seems like that could cause spurious latches
and when you fixed that you get no latches at all?
one time I got the spurious "keep latching" behavior; the rest of the time I got no latches
[3319559.880984] hm2/hm2_5i20.0: IO Pin 071 (P4-47): Encoder #0, pin Probe (Input)
I wonder if this means it's the latch only for encoder 0
.. looking at hostmot2.vhd I think maybe not
in the entity declaration of the quadrature counters, the pins that are different for each instance look like
quada => QuadA(i),
and the ones that are common look like
clk => clklow
and that's how probe looks:
probe => Probe,
I think there's no way in the idrom to specify "this pin corresponds to all instances"
-- Quadrature counter input signals
signal Probe : std_logic; -- only 1!
it was only a matter of time!
any troubleshooting suggestions when I'm back at my system with the 5i20 ?
I was thinking of usng 0x40 as a "global pin" flag
the current driver would report that as some pin on encoder 64
I didn't even look at how many bits are available, but using the highest value would make sense if there are plenty of bits
I just poked at the registers, didn't see any trouble but I can do a more thorough test
when i get a chance I could change the edge detection so you could change ProbePol
dynamically without generating a latch signal
(I just copied the index logic that assumes index polarity is a static setup option)
8 bits for each pin of a given module but bit 7 is already used as =outout
mozmck_work1 is now known as mozmck_work
hm, what raw register writes would I use to enable the encoder module if I load hm2 with encoders=0?
just so I know that all of the hal driver is staying out of my way
I dont think you need to do anything (encoder module is all inputs and defaults are reasonable)
I can make a new bitfile with ability to dynamically change probe polarity if that would help
but it may be that the driver is messing with the probe bits
I think that ultimately that will be needed
but I can structure my testing now to avoid the problem
actually, I could probably structure the hostmot2 driver to avoid the problem
by making sure to write the polarity before the enable
Its a trivial change in the encoder
I would only change rev 3 counters (now compiled in only when a probe pin is found)
as some existing configs are very close to not fitting
I would probably change it for index as well
the other alternative we'd talked about is having separate bits for "on rising edge" and "on falling edge" (so we could turn on both), but the way I'm structuring emc that won't be needed.
the motion controller will have an output that tells you which edge (just one) is desired
Yes, I wish I'd done that at the beginning.
I kind of dont want the mechanism to be different for probe and index
but doing it for both would cause pain and suffering unless the driver
checked the encoder rev and DTRT
EMC: 03cradek 07random_toolchange * r5fa491d570d9 10/src/emc/ (9 files in 5 dirs): Merge branch 'master' into random_toolchange
(this code already does what I want; how can I make it do enough of what everyone else wants that I can merge it adequately in good conscience?)
currently in nonrandom toolchanger machines, we have a column in the tool table that does nothing. if I continue to have a column that does nothing on those machines, all tool tables can have the same number of columns. (In a random machine, that extra column is the pocket number.)
is this the least bad of all possible worlds? it doesn't break any existing tool tables, but they still have extra crap in them.
how did you mark which tool is in the spindle ?
today on nonrandom machines, that information is not kept in the tool table.
I think that leaving the crap in there is the best thing to do
restarting emc makes it forget what tool is in the spindle, which might be considered a feature, if you want T[that tool]M6 to cause a tool change operation subsequently
there's no sense having multiple tool table (or anything else) formats if it's avoidable, unless we put in a method of determining the revision of the tool table (or whatever) format
I had "improved" this (to my eye) but the changes are universally reviled
not universal - you like it
now I just want to merge it but not have people bother me
use someone else's account
I've been meaning to introduce a new developer - he's not from around here - his name is yabzsucy
he's interested in merging my changes, and he doesn't seem to care what you guys think
but seriously, leave the extra crap in the file and maintain compatibility? and forget trying to add the remembered-tool-in-spindle feature?
i just thinking if u have a 20ATC u can have 21 tools in the machine so i wunderd how on turn on or other you knew which tool out of the 21 was in spindle at the time or ud never find tool 21 in the ATC as it would be in the spindle
you can't necessarily have an extra tool in the machine
with random_toolchange you can have 21 tools in a 20ATC machine just fine
there has to be an empty space to put the one in the spindle back into
that's nothing special - just a consequence of how it works
(depending on the mechanics)
only on a unbrella, random has swing arm so u can keep pocket near spindle full
SWPadnos: no, because they always swap between spindle and a pocket
the spindle is just like another pocket
true, I suppose this change is only necessary/desirable on machines that swap the tools
yes that has been done and working for months - now I want to make it sane on non-swapping machines too
on those, if you shut down without putting all the tools away, you're screwed, and I'm going to not change that
you can still scribble on the FMS column in non-random tool files
to what end?
so you can write "-1" or whatever to the FMS value for the tool in the spindle
and when it's put back, write the pocket number again
as I understand it, it's a misfeature to remember what tool is in the spindle
at tool table load, look at all the FMS numbers, and if exactly one is -1, set that as the one in the spindle
sure, like everything, there's no guarantee that things haven't changed
seems like I/we can't seem to say how it SHOULD work so the only sane thing I can do is not change how it currently works for those machines
also, there are potential HAL issues with the initial tool number
yeah, that's probably the best thing
one thing I do want to keep is arbitrary tool number allowance
"can't have tool numbers over 54" is just stupid
well, that depends
the current code doesn't differnetiate between pockets and tool numbers, right?
well which current code?
the current non-random code
the tool number is the number output on the HAL pin when a tool prep is requested
yes on master it swirls them together
so there may be assumptions about tool numbers in the HAL/CL setup for existing machines
since they can't be above 54 now
yes today using master, the user has no choice but to assume pocket/tool are the same number
maybe I should also preserve that swirliness
so there would have to be some HAL changes, even if it's just to connect a different HAL pin to the toolchange logic
in the random branch, you get two hal pins so you have pocket and tool# both
since you need two pins to support both modes - tool number and pocket number
even today, someone could use the random branch and ignore the pocket# everywhere
the lines would move around in the tool table - who cares
unless they get a file with a tool number 759
they would get the spindle-remember feature
no, that WOULD work
(assuming it's even practical to email tool files around ...)
well, they'd need the toolchange code to be able to get to pocket 759
in the random branch you can have tool 9999999999 as long as you stick it in a pocket <54
no no no
14:24 <cradek> even today, someone could use the random branch and ignore the pocket# everywhere
ok, so they'd have to change to use the pocket # pin
are those incorrectly named then?
well it depends what their tool changer wants. if it has barcodes they might want the tool#
I'm talking about existing machines, which by definition do not have tool numbers above 54
if they assume tool=pocket they could use the random branch and consider the tool hal pin the pocket# for their changer to use
so the tool pin gets the pocket number?
(sorry if I'm being dense here)
is it an error now to specify a tool number > 54?
in the random branch, you have tool# and pocket# in the tool table. when you prep a tool you get both those numbers in hal.
if your tc is random, you want the pocket
if your tc is nonrandom, you might use the tool
hm, nonrandom kind of sucks
there is no ability/need to prep
surly if its non random the tool# and pocket# will always match only the tool in use (in the spindle) will be marked as inspindle within the TBLK untill put back no?
what is TBLK?
tbl sorry too many letters
maybe in nonrandom, you just trust the carousel/umbrella to not have turned, and you cram the old tool in the nearest pocket
* skunkworks_ has 60 pockets...
skunkworks_: you'll never get it running at this rate, so it doesn't matter
i say depends what u want there, for me the unbrella has a index switch so u know when it has indexed or not
skunkworks_: sorry... :-)
skunkworks_: are your motor drivers ready for it?
all I can say is I have not blown one up yet...
(and I only have one made atm)
dad raised a section of roof in the polebulding to put a car lift in - so he has been busy with that. (and I have been just busy)
so there mister 'I can convert a machine in less than a month'
man that would be nice...
skunkworks_: it did go pretty fast, didn't it
for as many bad parts as I had... if it had been a running machine it would have been very fast.
are you still runnig the original style servo amps?
I think the Y tach has a problem - sometimes it goes thunk thunk thunk when jogging - plotted it - exactly once per screw turn
(to replace the bad ones?)
yes identical to the originals
yeck - do you have any extras?
I have two dead-ish ones
the 200 amp sevice gets hooked up next tuesday to the garage..
That will be nice. I need to get a corner of it setup for a shop - need to get all my tools in one spot.
dangit I haven't made any progress
maybe coffee will help
[19:56:04] <skunkworks_> http://cgi.ebay.com/ADVANCED-MOTION-CONTROLS-SERVO-AMPLIFIER-100A25H_W0QQitemZ110392339038QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item19b3e56a5e
did you see where it says "I don't expect to get this much" in the auction text?
heh - no
I should make him an offer...
close enough, if you read it right
> Feel free to make an offer and ill consider it.
an ill-considered offer?
maybe he has swine flu