Back
[10:25:13] <skunkworks> was there an easy way to get the latest rt-prempt on wheezy? the 4 soemthing?
[10:25:28] <skunkworks> last time I was building it
[10:34:07] <KGB-linuxcnc> 03Dewey Garrett 052.7 ee972cc 06linuxcnc 10debian/linuxcnc.files.in 10debian/rules.in debian/rules.in: make soft link for nc_files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ee972cc
[10:36:05] <KGB-linuxcnc> 05dgarr/missinglink c6630a1 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c6630a1
[10:59:53] <Roguish> skunkworks:
http://linuxcnc.org/docs/2.7/html/getting-started/getting-linuxcnc.html#_installing_on_debian_wheezy_with_preempt_rt_kernel
[11:00:17] <Roguish> just did it last week.
[11:10:34] <skunkworks> Roguish: thanks - I was just wondering if there was newer packages already made for rt_preempt and wheezy
[11:12:41] <mozmck> I don't think so.
[11:13:53] <pcw_home> I think jepler mentioned that a 4.x Preempt-RT kernel is now in the Debian backports repository
[11:14:26] <mozmck> for jessie anyhow...
[11:21:19] <seb_kuzminsky> jessie-backports has an rt-preempt linux-image for linux 4.1
[11:22:18] <seb_kuzminsky> we don't yet build linuxcnc debs for that kernel, though i wonder if the wheezy uspace debs might work (except for the libgnomeprintui dependency)
[11:27:02] <cradek> 15 20:35 <jepler> so scratch that: linuxcnc-uspace from wheezy debs on jessie doesn't work
[11:28:37] <seb_kuzminsky> whoops
[11:29:37] <seb_kuzminsky> what was the problem?
[11:30:35] <cradek> 15 20:32 <jepler> the debian wheezy packages can be installed on a jessie system that was updated from wheezy, but some packages not available in jessie are pulled in in the process
[11:36:27] <seb_kuzminsky> is "15" the date?
[11:40:03] <skunkworks> pcw_home: what config would have for the 7i80 - 7i48+7i44
[11:40:33] <pcw_home> maybe svss6_6
[11:40:48] <pcw_home> (for a 7I80HD)
[11:41:19] <skunkworks> right thanks
[11:43:40] <skunkworks> pcw_home: 7i80hd_16_svss6_6.bit?
[11:44:23] <pcw_home> yeah (mesaflash --readhmid is probably in order just to verify)
[11:45:39] <pcw_home> there are some SVSS configs fro the 7I52 but I think they all have 7i52 in their names
[11:47:32] <skunkworks> pcw_home: after flashing.. ;)
http://pastebin.ca/3112221
[11:48:05] <skunkworks> wait - how does that work connecting the 7i44?
[11:48:20] <skunkworks> seems like it is on the fist port
[11:48:23] <skunkworks> first
[11:48:25] <pcw_home> oops thats a 7I52 config, so much for my naming theory
[11:48:54] <skunkworks> good thing it is easy to program.. ;)
[11:49:10] <pcw_home> maybe svss6_8
[11:50:23] <pcw_home> sorry, forgot the 7I44 was 8 channels
[11:50:57] <skunkworks> better :)
http://pastebin.ca/3112232
[11:51:22] <pcw_home> yep that looks right
[11:54:25] <pcw_home> actually the Ethernet cards are the fastest to program
[11:58:23] <pcw_home> a good addition to mesaflash would be a test config option where a config is loaded in free space in the EEPROM
[11:58:24] <pcw_home> (theres room for 2 m ore configs on most cards) and a reload started from that area, so if it goes wrong
[11:58:26] <pcw_home> a power cycle will recover
[11:59:27] <pcw_home> does require some ICAP magic to start a FPGA reload from and arbitrary address
[12:22:04] <skunkworks> is there something different I have to do to use opto-22 boards with the 7i80?
[12:22:29] <pcw_home> should not be
[12:22:49] <pcw_home> you do need open drain mode
[12:36:11] <skunkworks_> pcw_home: I have the jumper set to send voltage down the line..
[12:36:52] <skunkworks_> I measure 3.3v at the board.
[12:37:11] <skunkworks_> (after I set the jumper)
[12:42:36] <pcw_home> w6,7,8 up?
[12:46:20] <skunkworks_> do they all have to be set? I only set the middle port
[12:48:41] <pcw_home> well all of our daughtercards are 5V so theres not much reason for using 3.3V unless you need it
[13:03:02] <skunkworks> ok - I do measure 5v at the
[13:03:09] <skunkworks> with all up.
[13:03:29] <skunkworks> I remember the ouputs would glow dimly without opendrain true
[13:09:57] <skunkworks> ok - the numbering on the boards are revearsed i/o 44 is actually 3
[13:10:26] <skunkworks> yay a start
[17:09:38] <skunkworks> ugh
http://www.cnczone.com/forums/linuxcnc-formerly-emc2-/260140-cnc-tormach.html#post1747790
[17:30:06] <seb_kuzminsky> how's that song go? you can please some of the people, some of the time?
[17:52:42] <zeeshan-mill> ive tried search for this answer with no luck
[17:52:59] <zeeshan-mill> parameters like MAX_ACCELERATION in the .ini -- is there anyway to set these through halcmd
[17:53:00] <zeeshan-mill> for testing purposes
[17:54:05] <andypugh> zeeshan-mill: No, they are motion parameters, which all happens before HAL.
[17:54:14] <zeeshan-mill> damn.
[17:54:25] <zeeshan-mill> i keep on having to close my linuxcnc
[17:54:32] <zeeshan-mill> and change the parameter in ini and restart :P
[17:54:42] <zeeshan-mill> i am using halscope , which is why im doing it like this
[18:02:42] <skunkworks> there is a branch iirc that exposed them as hal pins.. something dewey was working on..
[18:20:58] <dgarr> zeeshan-mill: in 2.7 there are pins like ini.n.max_acceleration, ini.n.max_velocity (they are sampled when a program is _not_ running) you can set them in a halcmd terminal or use a simple gui named sim_pin
http://www.linuxcnc.org/docs/2.7/html/hal/tools.html#_sim_pin
[18:21:42] <zeeshan-mill> Sweet!
[18:28:51] <dgarr> you can also make a sim_pin config and/or a halscope config and make them start up each time with ini file settings like [APPLICATIONS] APP = halscope -i settings.halscope and APP = sim_pin ini.0.max_acceleration ini.1.max_acceleration etc.
http://www.linuxcnc.org/docs/2.7/html/config/ini-config.html sec 2.9
[18:41:55] <dgarr> ini pins and their limitation are described in milltask man page; www.linuxcnc.org/docs/2.7/html/man/man1/milltask.1.html
[18:45:11] <skunkworks> dgarr: wow - I didn't know it made in the main line
[18:47:32] * zeeshan-mill needs to upgrade to 2.7
[18:47:42] <zeeshan-mill> great job making these changes
[18:47:47] <zeeshan-mill> this will help in tuning a lot.
[18:48:10] <dgarr> i guess the ini pins are in 2.6 too: git branch --contains e5858b2 says 2.6 and 2.7 you can see if they are in your version with $ halcmd show pin ini\*
[18:48:45] <zeeshan-mill> nope
[18:48:46] <zeeshan-mill> not there
[18:48:59] <zeeshan-mill> wait
[18:49:01] <zeeshan-mill> they are.
[18:49:02] <zeeshan-mill> lol
[18:49:16] <zeeshan-mill> thank you!!
[18:51:05] <zeeshan-mill> man this speeds things so much.
[19:07:19] <andypugh> Sorry, seems I gave bad advice.
[19:21:27] <skunkworks> I do that all the time