Back
[01:33:36] <KGB-linuxcnc> 03seb 05motion-tests 82cc9da 06linuxcnc 10tests/motion/ 10(5 files) * remove the motion/g0 test
[01:33:36] <KGB-linuxcnc> 03seb 05motion-tests 2b8f52e 06linuxcnc 03lib/python/linuxcnccontrol.py * make LinuxcncControl a reusable python library
[01:33:39] <KGB-linuxcnc> 03seb 05motion-tests 00f6fc8 06linuxcnc 10tests/ 10halui-jogging/test-ui.py 10toolchanger/m61/test-ui.py * tests: use the new LinuxcncControl python module
[01:33:46] <KGB-linuxcnc> 03seb 05motion-tests 7d209b0 06linuxcnc 10tests/motion/ 10(9 files in 2 dirs) * tests: add a motion test of the X-axis g0 vel/acc profile
[01:33:52] <KGB-linuxcnc> 03seb 05motion-tests 6d43268 06linuxcnc 10tests/motion/ 10(5 files) * tests: add a motion test of jogging the X axis
[01:33:59] <KGB-linuxcnc> 03seb 05motion-tests 05c4605 06linuxcnc 10tests/motion/README * README
[01:34:05] <KGB-linuxcnc> 03TODO: deletor 05test-g0 fbe9298 06linuxcnc 04. * branch deleted
[02:20:43] <linuxcnc-build> build #676 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/676 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:25:29] <linuxcnc-build> build #1475 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1475 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:28:30] <linuxcnc-build> build #1476 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1476 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[08:36:22] <SadMan> http://pastebin.com/TLQsDQrL
[08:36:35] <SadMan> any idea? seems to die on inb(0x37a), some permission problems?
[08:41:11] <skunkworks__> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewRTInstall
[08:41:38] <skunkworks__> maybe the section
[08:41:38] <skunkworks__> Before running any parallel-port based configuration, make sure the 'lp' kernel module is not loaded.
[08:42:06] <SadMan> that's unloaded, i was getting cannot open instead of crash when lp was loaded
[08:42:11] <skunkworks__> also - did you add your user to the xenomai and kem group?
[08:42:17] <SadMan> yes
[08:42:22] <skunkworks__> huh
[08:42:28] <SadMan> uid=1000(cnc) gid=1000(cnc) groups=1000(cnc),4(adm),7(lp),15(kmem),24(cdrom),27(sudo),30(dip),46(plugdev),111(lpadmin),112(sambashare),115(xenomai)
[08:43:08] <skunkworks__> That is about all I have for troubleshooting knowledge..
[08:43:24] <SadMan> ok, thanks for trying ;-)
[08:43:53] <skunkworks__> I have run the xnomai kernel with linuxcnc - it does work. (if that is any consolation ;) )
[08:44:33] <SadMan> it's probably something really stupid, i just ran out of ideas
[08:56:39] <skunkworks__> did you sudo make setuid?
[09:01:59] <SadMan> yes
[09:02:54] <SadMan> core file is owned by root too
[10:54:32] <KGB-linuxcnc> 03seb 05motion-tests 0817634 06linuxcnc 10tests/motion/ 10jog/test-ui.py 10mdi/g0/test-ui.py * handle realtime errors better
[10:55:13] <skunkworks__> mhaberler, SadMan is havinng issues still - read back
[10:55:22] <mhaberler> SadMan: please pastebin /var/log/linuxcnc.log
[10:55:32] <skunkworks__> heh
[10:55:45] <SadMan> http://pastebin.com/TLQsDQrL
[10:55:47] <mhaberler> need to edit the wiki and 'our mascot' seems not to be 'tux'
[10:56:03] <mhaberler> that is the console log
[10:56:15] <skunkworks__> mhaberler, I think it is chips
[10:56:17] <mhaberler> ah
[10:56:19] <mhaberler> I see
[10:56:23] <SadMan> actually i just made it not crash by adding iopl(3) here and there which is completely wrong because it works for everyone else ;-)
[10:56:47] <mhaberler> please do this as per the link I gave: export DEBUG=5
[10:57:02] <mhaberler> then run again and post /var/log/linuxcnc.log
[10:57:10] <mhaberler> have you been changing C source?
[10:57:30] <SadMan> just now, tried to add iopl before those inbs whether it helps
[10:57:32] <SadMan> it does
[10:57:33] <mhaberler> also please run 'flavor' and report the outoput
[10:58:17] <mhaberler> we need to find the actual cause, rtapi_app is supposed to elevate iopl levels properly
[11:01:12] <SadMan> flavor reports xenomai
[11:01:15] <SadMan> http://pastebin.com/4KgU64ZN
[11:01:29] <SadMan> (i've removed those iopls)
[11:11:01] <mhaberler> you did insert the iopl() somewhere before hal_parport.c:608 I assume?
[11:11:33] <SadMan> had to do that in 2 functions, read and setup
[11:11:37] <SadMan> now i removed
[11:11:40] <SadMan> //#if defined(__x86_64) || defined(i386)
[11:11:47] <SadMan> in ./rtapi/rtapi_app.cc
[11:11:51] <SadMan> and it works again
[11:12:01] <SadMan> something wrong with defines
[11:12:21] <mhaberler> no, environment or options
[11:12:26] <SadMan> iopl is compiled out in my case
[11:12:57] <mhaberler> can you please verify with a piece of C like so:
[11:13:51] <mhaberler> #if defined(__x86_64) || defined(i386)
[11:13:51] <mhaberler> #warning "this warning MUST appear"
[11:13:52] <mhaberler> #endif
[11:14:06] <SadMan> i'm back in 20 mins, i'll try it then
[11:14:35] <mhaberler> ok
[11:18:39] <mhaberler> skunkworks_:thanks - it is; to derive that string from 'the name of our mascot' is beyond my cultural sensitivity level ;)
[11:21:28] <skunkworks__> heh
[11:23:22] <cradek> mhaberler: it's also the name of the image
[11:25:24] <mhaberler> ah
[11:25:44] <cradek> I thought that would be a dead giveaway, but nobody seems to find it
[11:26:02] <mhaberler> well it sure dont come easy to me
[11:26:22] <mhaberler> saying 'basename of mascot image file' might provide a clue
[11:26:29] <cradek> fortunately you knew where find the answer easily
[11:28:53] <mhaberler> Sadman: please pastebin src/config.log, and report output of this (for gcc and g++): gcc -dM -E - < /dev/null | grep 86
[11:29:05] <mhaberler> this is seriously whacky
[11:36:09] <mhaberler> SadMan: it would help if you could gdb rtapi_app core and in the main() frame report the values of 'use_drivers' and 'flavor->flags'
[11:50:26] <SadMan> there's #define i386 1 in both gcc and g++ output of those commands above
[11:50:44] <SadMan> if i add that #define above that iopl if defined, it gets compiled in
[11:50:51] <SadMan> no idea where it disappears
[11:51:52] <mhaberler> please touch src/rtapi/rtapi_app.cc and 'make V=1', then post the make output (which should list the gcc command line with all flags)
[11:52:05] <SadMan> ok
[11:52:13] <mhaberler> I've never seen this in the wild
[11:53:40] <SadMan> g++ -c -I. -Ilibnml/linklist -Ilibnml/cms -Ilibnml/rcs -Ilibnml/inifile -Ilibnml/os_intf -Ilibnml/nml -Ilibnml/buffer -Ilibnml/posemath -Irtapi -Irtapi_export -Ihal/drivers -Ihal -Iemc/nml_intf -Iemc/kinematics -Iemc/motion -Iemc/ini -Iemc/rs274ngc -Iemc/pythonplugin -I/usr/include/python2.7 -g -O2 -std=c++0x -DULAPI -g -Wall -Os \
[11:53:40] <SadMan> -MP -MD -MF "objects/rtapi/posix/rtapi_app.d" -MT "objects/rtapi/posix/rtapi_app.o" \
[11:53:41] <SadMan> rtapi/posix/rtapi_app.cc -o objects/rtapi/posix/rtapi_app.o
[11:54:01] <mhaberler> let me check if -std=c++0x is the cause
[11:54:51] <SadMan> yes, that one looks suspicious ;-)
[11:54:52] <mhaberler> no it isnt
[11:55:28] <mhaberler> well I have gcc 4.8.2 here, could you try with yours ?
[11:56:54] <SadMan> just to add that to g++ -dM -E - < /dev/null ?
[11:56:58] <SadMan> no difference
[11:57:00] <mhaberler> right
[11:57:42] <mhaberler> lets exclude the sym is #undef ed somewhere in the includes. could you add at the top of rtapi_app.cc:
[11:57:51] <mhaberler> #ifndef i386
[11:58:09] <mhaberler> #error "i386 not defined"
[11:58:12] <mhaberler> #endif
[11:58:15] <mhaberler> and rebuild?
[11:58:47] <mhaberler> if it is #undef'd from the command line already that should fail the compile
[11:59:08] <SadMan> rtapi/posix/rtapi_app.cc:2:2: error: #error "i386 not defined"
[11:59:15] <mhaberler> whoa
[11:59:25] <mhaberler> now..
[11:59:46] <mhaberler> does this happen if you execute in src:
[12:00:16] <mhaberler> g++ -c -I. -Ilibnml/linklist -Ilibnml/cms -Ilibnml/rcs -Ilibnml/inifile -Ilibnml/os_intf -Ilibnml/nml -Ilibnml/buffer -Ilibnml/posemath -Irtapi -Irtapi_export -Ihal/drivers -Ihal -Iemc/nml_intf -Iemc/kinematics -Iemc/motion -Iemc/ini -Iemc/rs274ngc -Iemc/pythonplugin -I/usr/include/python2.7 -g -O2 -std=c++0x -DULAPI -g -Wall -Os -MP -MD -MF "objects/rtapi/posix/rtapi_app.d" -MT "objects/rtapi/posix/rtapi_app.o"
[12:00:16] <mhaberler> rtapi/posix/rtapi_app.cc -o objects/rtapi/posix/rtapi_app.o
[12:00:17] <mhaberler> ?
[12:00:37] <mhaberler> (to exclude environment passed in from make)
[12:01:30] <SadMan> yes
[12:01:39] <mhaberler> same error you mean?
[12:01:45] <SadMan> yes, #error
[12:01:55] <mhaberler> good, so not environment coming in via make
[12:02:14] <mhaberler> g++ --version says?
[12:02:18] <SadMan> heh, i've removed -std=c++0x and it compiled
[12:02:25] <mhaberler> what!?
[12:04:06] <jepler> same result with g++ 4.4.3 on ubuntu lucid
[12:04:08] <jepler> http://pastebin.com/6K6gZP4k
[12:04:28] <jepler> the "i386" identifier is reserved to the user, and so -std=c++0x turns it off
[12:04:36] <jepler> -std=gnu++0x enables it as a gnu extension
[12:05:04] <mhaberler> hm, should we throw in -std=gnu++0x ?
[12:05:27] <jepler> __i386__ and __i386 are both defined and those are probably "the right way" because they are identifiers reserved to the implementation
[12:05:54] <jepler> so -std=gnu++0x is possibly the shortest path to a working system
[12:06:18] <jepler> but the better long-term solution may be to use __i386
[12:06:44] * jepler wanders off again
[12:08:07] <mhaberler> this still doesnt add up for me: I do 'gcc -std=c++0x -dM -E - < /dev/null | grep 86' and get '#define __i386 1' as well as '#define i386 1'
[12:08:36] <SadMan> i had g++ warning me that -std is only valid in c++ mode
[12:08:39] <SadMan> could be the reason
[12:09:36] <jepler> yes
[12:09:47] <jepler> for whatever reason, "-" is assumed to be a C (not C++) source file by g++
[12:09:52] <mhaberler> well we definitely need reliable architecture detection symbols regardless of invocation
[12:10:08] <jepler> $ g++ -std=c++0x -dM -E - < /dev/null | grep cplus
[12:10:09] <jepler> cc1: warning: command line option "-std=c++0x" is valid for C++/ObjC++ but not for C
[12:10:10] <mhaberler> jepler: are you suggesting __386 would work regardless?
[12:10:12] <jepler> $ g++ -std=c++0x -dM -x c++ -E - < /dev/null | grep cplus
[12:10:14] <jepler> #define __cplusplus 1
[12:10:17] <mhaberler> __i386 I mean?
[12:10:31] <jepler> mhaberler: a sample of one computer suggests it may be so
[12:11:09] <mhaberler> was that off the top of your head or from a reference?
[12:11:18] <jepler> top of my head. I wish I had a reference
[12:11:27] <SadMan> so for me, it should be enough to edit this after ./configure and before rebuild?
[12:11:28] <SadMan> ./Makefile.inc:CXXFLAGS = -g -O2 -std=c++0x
[12:11:34] <mhaberler> right
[12:12:29] <jepler> closest I have is:
http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html
[12:13:01] <jepler> so it sounds like __i386__ is a better choice than __i386 or i386
[12:13:38] <jepler> but a compiler test for iopl being available might be better still
[12:13:41] <jepler> for this specific instance
[12:13:50] <mhaberler> well as a fix which will work for exactly 1 configure - yes, but I think we should have a patch shortly to
[12:13:56] <jepler> really afk this time
[12:14:23] <mhaberler> hm, that would suggest with #if defined(__x86_64) || defined(i386) the first one is rightish and the second wrongish
[12:14:49] <mhaberler> SadMan: could you retry by editing #if defined(__x86_64) || defined(i386) into #if defined(__x86_64) || defined(__i386)
[12:14:53] <mhaberler> and rebuild?
[12:16:14] <mhaberler> ah, it should be __i386__, sorry
[12:16:21] <mhaberler> amd __x86_64__
[12:16:32] <mhaberler> trying now here
[12:16:52] <SadMan> if you're not compiling on atom as i do, you'll be faster ;-)
[12:17:54] <mhaberler> dang, there's a single second use in the code for x86_64 and it is correct if one believes the above:
[12:17:55] <mhaberler> ./rtapi/rtapi_time.c:#elif defined(__i386__) || defined(__x86_64__)
[12:18:10] <mhaberler> oh, it should just rebuild that single file
[12:18:31] <SadMan> yes, it works
[12:20:48] <KGB-linuxcnc> 03git 05unified-build-candidate-3 2ed738b 06linuxcnc 10src/rtapi/rtapi_app.cc * rtapi_app: correct usage of architecture symbols
[12:21:11] <mhaberler> great, you could pull --force and rebuild, it's fixed
[12:21:15] <mhaberler> thanks for the patience!
[12:21:26] <SadMan> thanks for fix ;-)
[12:21:37] <mhaberler> Jeff - thanks, learned something!
[12:22:30] <mhaberler> SadMann: so startup is ok now?
[12:22:49] <SadMan> yes, it "boots" to gui now
[12:22:53] <mhaberler> super
[12:23:09] <mhaberler> very tricky..
[12:25:50] <mhaberler> ok, bbl - mail ok
[12:28:32] <andypugh> Any opinions on that augmentation of charge-pump that was seen on the mailing list today?
[12:34:35] <seb_kuzminsky> andypugh: seems like a quick safe fix, and easy for users to understand, though a bit arbitrary
[12:35:10] <andypugh> Arbitrary in only being /2 and /4 ?
[12:35:30] <seb_kuzminsky> yeah, /2 and /4 probably covers a lot of the common cases, but exposing a divisor and letting the user set it seems cleaner to me
[12:35:44] <skunkworks__> My thought... Why make the person figure out the frequency.. couldn't you have the hal module take the frequency and output a 'close enough' frequency maybe by dithering?
[12:35:51] <skunkworks__> *input
[12:36:02] <seb_kuzminsky> skunkworks__: yeah, i like that
[12:36:21] <andypugh> We have other compnents for that. Charge-pump is meant to be fast and lightweight
[12:37:18] <andypugh> It's just meant to wiggle a pin to show that it is alive.
[12:38:22] <seb_kuzminsky> andypugh: things that get poked by the charge-pump comp are pretty generous in what frequencies they accept, so /2 and /4 seems like an easy improvement
[12:39:03] <andypugh> That was my thinking. If someone needs a specific frequency then they probably need to look at a 50% duty cycle version of PWM.
[12:40:01] <andypugh> Until last week I hadn't seen anyone unhappy with the existing version.
[12:53:22] <linuxcnc-build> build #1478 of hardy-amd64-sim is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1478 blamelist: Michael Haberler <git@mah.priv.at>
[12:59:07] <linuxcnc-build> build #1473 of hardy-i386-realtime-rip is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1473 blamelist: Michael Haberler <git@mah.priv.at>
[13:00:20] <linuxcnc-build> build #1476 of hardy-i386-sim is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1476 blamelist: Michael Haberler <git@mah.priv.at>
[13:40:47] <linuxcnc-build> build #1478 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1478 blamelist: Michael Haberler <git@mah.priv.at>
[18:50:47] <KGB-linuxcnc> 03andy 05master 9af287f 06linuxcnc 10src/hal/components/charge_pump.comp * Add two lower-frequency pins to charge_pump for hardware that expects such.
[19:43:31] <cradek> can't you make a slower thread of any exact frequency you want?
[19:45:20] <cradek> another interesting question is whether this works during the rollovers (I think it's a signed int by default, right?)
[20:12:37] <cradek> testing shows that it appears to work
[20:20:15] <seb_kuzminsky> signed, unsigned, shouldnt matter with the bit ops
[20:21:04] <seb_kuzminsky> a slower thread specially for the charge pump seems like it should work, but it's probably in the domain of "more complicated to configure than a charge pump should be"
[20:51:43] <cradek> as long as it works (and I believe you that it does) I don't have strong hygiene-related objections
[20:52:08] <cradek> so aside from a bit of a weird feeling it's fine and I'll stop thinking about it
[21:08:06] <jepler> cradek: the way motion creates its two threads it's inconvenient to create a thread of your own of intermediate frequency
[21:09:17] <cradek> oh - I thought it was fine as long as you wanted something slower than the fast thread
[21:09:33] <jepler> threads also have to be created from fastest to slowest
[21:10:49] <cradek> you are right - the manpage says that
[21:10:52] <cradek> I had no idea
[21:15:50] <cradek> unloading and reloading threads to create more than three threads, as the manpage says to do, doesn't work - the original three just disappear
[21:16:00] <cradek> so I have no idea how to even try this
[21:16:12] <jepler> hmm
[21:18:39] <jepler> seb seems to be right that the & operator on a signed value is defined. I worried that it might be undefined since the C standard is written to allow one's complement and two's complement arithmetic, but clang 3.3 -fsanitize=undefined does not mind the expression '(-1) & 2'
[21:19:06] <jepler> (-1) << 1 is an undefined expression
[21:20:25] <skunkworks> The stock code in axis is a surprisingly good test for these changes. <RobE :)
[21:21:12] <cradek> I also wondered about 1s-c but that's not even a thing anymore is it?
[21:21:37] <cradek> (I guess 10 years ago we thought the whole world was little endian for good...)
[21:23:34] <jepler> The C99 standard explicitly allows for three (!) possibilities of the interpretation of the sign bit
[21:24:18] <jepler> it can negate the value (be an actual sign bit), it can have the weight -(2^(n-1)), or it can have the weight -2^(n)
[21:25:04] <jepler> & operates on bits, so I think the actual value of (-1) & 2 differs on platforms with these different characteristics, but it would still give 50% the frequency except for a possible discontinuity when changing sign
[21:28:05] <pzpz> hi
[21:28:27] <jepler> actually that overflow is considered undefined by clang
[21:28:35] <jepler> 5 int i = INT_MAX;
[21:28:35] <jepler> 6 if(i & 2) printf("something about the second low bit\n");
[21:28:35] <jepler> 7 i++;
[21:28:40] <jepler> lowbit.c:7:6: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
[21:45:50] <pzpz> hi
[21:48:20] <pzpz> what is the best way you make a 5 axis cnc, servo spindle, atc folding digitaiser and 2 extruders for 3D printing?
[21:56:35] <pzpz> ?
[21:56:37] <pzpz> what is the best way you make a 5 axis cnc, servo spindle, atc folding digitaiser and 2 extruders for 3D printing?
[22:07:27] <kwallace> Carefully.
[22:12:34] <pzpz> i go lost in the controler
[22:13:06] <pzpz> i make a simple step / dir 3 axis base on lpt
[22:13:15] <pzpz> but i want more...
[22:14:51] <kwallace> You can have more, just add to what you have.
[22:15:48] <pzpz> and i dont know if the linux will support it..
[22:17:09] <pzpz> 13 motors....
[22:17:44] <seb_kuzminsky> pzpz: linuxcnc can manage up to 9 motors for coordinated motion
[22:18:08] <seb_kuzminsky> you can have more than that if you're willing to run them independently of each other (ie, without their motions being coordinated with each other)
[22:18:48] <pzpz> is 5 axis machine
[22:19:14] <pzpz> 2 motor for ATC (1 select too 1 cover)
[22:19:15] <kwallace> that's five plus the extruder motors.
[22:19:31] <pzpz> 2 extruder
[22:19:44] <pzpz> 2 folding the extruders
[22:20:06] <kwallace> ATC motors will most likely just need limit3 not motion.
[22:20:47] <pzpz> waht do you mean by "limit"
[22:21:29] <kwallace> I use the limit component for my carousel.
[22:22:22] <kwallace> http://www.linuxcnc.org/docs/html/man/man9/limit3.9.html
[22:25:32] <kwallace> Oops. I can't find my current .hal file, but limit handles a move from one location to a target location with a velocity ramp a the start and end.
[22:26:35] <kwallace> This is needed because motion is disabled during a tool change, but this may change in the near future.
[22:27:49] <pzpz> 5 axis
[22:27:49] <pzpz> 1 digitaizer fold
[22:27:49] <pzpz> 2 extruder
[22:27:49] <pzpz> 2 extruder fold
[22:27:49] <pzpz> 1 atc
[22:27:50] <pzpz> 1 atc cover
[22:27:52] <pzpz> 1 servo spindle
[22:30:23] <kwallace> Just the 5 axes and 2 extruders need the motion component. The other motors can use limit.
[22:31:11] <pzpz> so it 7 axis?
[22:31:34] <pzpz> if i add laser
[22:31:48] <pzpz> it is also limit?
[22:33:06] <kwallace> I don't know about extruders. They need to squirt at a rate that matches the XYZ motion. You would need to verify with a GGG guru.
[22:33:41] <kwallace> I think lasers are just on or off.
[22:34:50] <pzpz> i want to add a 10W laser for cutting thin stuff..
[22:37:02] <kwallace> I think the laser on/off can is controlled by a digital I/O g-code word.
[22:37:30] <kwallace> Oops, can be
[22:37:34] <pzpz> but i afraid from refleting - in 10W the reflecting is dangeres to
[22:39:16] <kwallace> You need to have an enclosure that has windows that filter your laser's wave length and safely vent the fumes.
[22:39:21] <pzpz> and you need air
[22:41:27] <pzpz> so laser is someting that i will add last..
[22:42:03] <kwallace> Bottom line is that LinuxCNC can support this if you have integrator level mechanical, electronics and software skills or are willing to learn.
[22:43:49] <pzpz> i'm best in solidworks and mechanic
[22:44:09] <pzpz> electronics also not bad
[22:44:46] <pzpz> software - i know a bit of python &
[22:45:05] <pzpz> but i work with linux years..
[22:50:20] <pzpz> kwallace, ^
[22:57:25] <kwallace> There are some different types of machines here including lasers:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Case_Studies
[23:02:49] <pzpz> i see this.
[23:02:50] <pzpz> http://www.anderswallin.net/wp-content/uploads/2008/09/dc_servo_schematic_2008jan19.pdf
[23:03:33] <pzpz> it use M5i20 but i have much more i/o
[23:04:06] <pzpz> so i'm not sure what card to buy
[23:08:12] <ju-emb> 5i23 is PCI and has 72 I/Os,
[23:08:34] <ju-emb> some lasers need PWM to regulate the strength
[23:09:58] <ju-emb> and as kwallace say's extruders need coordination with XYZ
[23:10:29] <ju-emb> extruders also need two directions
[23:11:01] <ju-emb> and if you do 3D printing you need PWM for the heater
[23:13:40] <pzpz> so the 5i23 can do all that?
[23:14:00] <ju-emb> I'm sure yes
[23:14:22] <pzpz> include the PWM?
[23:15:06] <ju-emb> she does it also with quiet good performance, you can use stepper or servo Motors all in hardware
[23:15:55] <ju-emb> look at the hm2 component
[23:16:32] <pzpz> what is the "hm2 component"
[23:18:36] <pzpz> http://pastebin.com/zMcBVz1B
[23:19:13] <pzpz> ju-emb, this is the complate spaces that i want..
[23:19:38] <ju-emb> just looking at it
[23:20:21] <pzpz> by servo i mean G320X driver is ok for me..
[23:22:20] <pzpz> about the atc and the folding motors - i think stepper will be also ok
[23:27:33] <ju-emb> That are some I/Os more than 5i23 has, so you need 5i22 it has 96 I/Os
[23:27:36] <ju-emb> have a look at the hostmot here
[23:27:38] <ju-emb> http://www.linuxcnc.org/docs/2.4/html/drivers_hostmot2.html
[23:28:02] <ju-emb> point 1.2 Firmware Binaries
[23:29:11] <pzpz> how you calculate the I/Os?
[23:29:31] <pzpz> motor = 2 i/o?
[23:29:47] <ju-emb> no
[23:30:11] <ju-emb> each on/off is one I/O
[23:31:30] <ju-emb> motors is:
[23:31:33] <ju-emb> for steppers
[23:31:35] <ju-emb> Enable, Step, Direction
[23:31:37] <ju-emb> for each stepper, here the enable could be a common for all steppers
[23:31:55] <pzpz> Enable?
[23:32:12] <ju-emb> that's to energize the drivers
[23:32:23] <pzpz> in the G302x i see only Step, Direction
[23:34:51] <pzpz> what do you mean by "energize the driver" the driver get the power from it's own power supplly
[23:36:43] <ju-emb> yes, but if the driver is energized, the motor doesn't turn without a signal to turn
[23:38:12] <ju-emb> if you de-energize them, you can move the motor by hand or a mechanical handle or something. that's impossible if the driver keeps the motor energized
[23:40:06] <ju-emb> on the Geckos that signal is called Disable
[23:40:40] <ju-emb> so if you use a Gecko you have Disable, Step Dir
[23:41:17] <ju-emb> But, as I say'd, the disable can be the same signal for all Stepper drivers
[23:41:48] <ju-emb> Servos need some more I/Os
[23:44:12] <ju-emb> depend on the servo drive you use you have several I/Os for PWM signals and at least 2 or 3 I/Os for the encoder
[23:45:51] <pzpz> the encoder not connect to the G320X?
[23:49:19] <ju-emb> G320 is a Step Dir drive
[23:50:04] <pzpz> it is not ok?
[23:50:41] <ju-emb> yes, from LCNC's point of view it is a stepper
[23:51:36] <pzpz> ok.. so how i can make a real sevo..
[23:51:44] <pzpz> servo*
[23:55:33] <ju-emb> servo in the real application of it's word can be a lot of systems:
[23:56:18] <ju-emb> Servo drive say's only, that it is a motor with feedback connected to a controller who handles that
[23:57:57] <ju-emb> So in general you have the encoder connected to the controller and the controller gives you a PWM signal for the Motor Amplifier