#linuxcnc-devel Logs
Mar 02 2018
#linuxcnc-devel Calendar
08:43 AM mozmck: I was sent a message by a guy on the forum, and the return email was linuxcncwebforum@gmail.com - which does not sound right. He did not get my response because he was on the linuxcnc IRC last night asking about it.
08:45 AM mozmck: jepler: do you know if messages sent through the forum have any way of being responded to?
08:48 AM mozmck: I found his email in the admin backend and responded.
08:55 AM jepler: mozmck: I don't know how that works. It is right that all outgoing mails from the forum are from that gmail address.
08:56 AM mozmck: Probably something to do with german privacy laws I bet. Makes it impossible to respond to emails sent from other members though unless you have access to the backend!
08:58 AM mozmck: The backend has been reeeeaaaallllyyy slow lately. Takes up to a minute to load a page or make any change!
09:01 AM jepler: I also have seen that the administrator pages are awful, and the administrator pages that access info about users are worse still
09:02 AM mozmck: Yeah, user pages is mainly what I look at - banning spammers and deleting their posts :-)
09:03 AM jepler: needless to say I don't have a clue WHY it is bad
09:04 AM mozmck: ok. just though I'd mention it - didn't know if it was just on my end or what.
09:05 AM jepler: no, I don't think it's just you
09:06 AM mozmck: Sometimes technology makes me want to dump it all and raise a garden for a living. If it weren't for property taxes...
09:09 AM jepler: over the 24 hour period ending this morning at 6:25AM EST, there were 287866 HTTP requests logged to the forum. Maybe 3 requests per second is just too much for our itty bitty web server
09:14 AM mozmck: That does seem like a lot.
09:20 AM jepler: hm, I broke it
09:21 AM jepler: ah it's back
09:21 AM jepler: I tried to "optimize" all the tables. One of them took quite a bit of time. I don't think it fixed anything.
09:22 AM mozmck: I wonder if the traffic is much higher the last week or so? It seems like it used to be decently responsive, but only recently so sluggish.
09:26 AM jepler: um now wtf has happened
09:27 AM jepler: -- Unit mysql.service has begun starting up.
09:27 AM jepler: Mar 02 10:26:36 forum.linuxcnc.org audit[11155]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/proc/11155/status" pid=11155 comm="mysqld" requested_mask="r" denied_mask="r" fsuid=106 ouid=106
09:27 AM jepler: the mysql service won't start up
09:28 AM jepler: I am sure rebooting isn't going to help, let me try that
09:29 AM mozmck: Hmm, that's odd - apparmor denied? About all I know about apparmor is that it is some sort of security thing.
09:30 AM jepler: yeah
09:32 AM jepler: ah those errors were red herrings
09:32 AM jepler: apparently they are part of the "normal" operation of apparmor
09:33 AM mozmck: huh, kinda like the check engine light on old cars :-)
09:39 AM jepler: they should just ship with a sort of reverse odometer which reads "time to new car loan:"...
09:41 AM mozmck: I think they want to go to a CAAS model - Car As A Service. You just pay a low monthy fee to use their cars for the rest of your life! I have never bought a new car and always paid cash. My payments a *very* low :-)
09:43 AM mozmck: bbl
09:58 AM jepler: pardon the paste
09:58 AM jepler: # Time: 2018-03-02T15:56:36.988961Z
09:58 AM jepler: # User@Host: joomla_user[joomla_user] @ localhost [] Id: 14
09:58 AM jepler: # Query_time: 9.244646 Lock_time: 0.000115 Rows_sent: 1 Rows_examined: 1225339
09:58 AM jepler: SET timestamp=1520006196;
09:58 AM jepler: SELECT COUNT(session_id)
09:58 AM jepler: FROM ptj_session
09:58 AM jepler: WHERE guest = 0 AND client_id = 1;
10:19 AM skunkworks: hmm - that could be why I never heard back from a forum member that emailed me through the forum
10:26 AM skunkworks: mozmck, I just sent you an email through the forum.. Can you reply to it?
10:29 AM jepler: I deleted a bunch of "Guest sessions" from history and now the administrator pages seem to come up faster
10:30 AM jepler: I don't know if we've hit a bug that causes that table to grow without limit, or what...
11:15 AM jepler: aha https://github.com/joomla/joomla-cms/pull/19548
11:15 AM jepler: > Since Joomla 3.8.4, if you use Database Session Handler, session data won't be deleted on page loads like in older version of Joomla anymore
11:15 AM jepler: we are on 3.8.5
11:18 AM jepler: so it will be fixed in 3.8.6 I guess
11:20 AM jepler: and also intersecting with a verra old debian php configuration choice http://bugs.debian.org/267720
11:21 AM jepler: .. it seems that joomla somehow ends up relying on this php.ini configuration value even though it is storing its configuration in the database, rather than in a place that the debian cleanup script touches
11:21 AM jepler: fffs
11:45 AM jepler: oh gee, the reason that dreamhost's help site is broken for me is because the content of every article is in a HTML element with the class "ad-content". so of course my ad blocker has adblocked it.
11:46 AM mozmck: haha!
11:46 AM mozmck: skunkworks: I got your email, but the return address is linuxcncwebforum@gmail.com I'll respond but I bet you won't get it.
11:47 AM jepler: er, digitalocean, not dreamhost, but the rest was accurate
11:47 AM jepler: yeah it does no good to email linuxcncwebforum@gmail.com
11:47 AM mozmck: Didn't figure, but I just did anyhow.
11:47 AM jepler: there's probably interesting stuff for me to read if I were to log in to that gmail account
11:48 AM mozmck: Heh! I bet.
11:49 AM mozmck: Oh wow, whatever changes you made to the forum backend have definitely sped it up.
11:50 AM seb_kuzminsky: jepler ftw
11:50 AM mozmck: yeah, thanks!
12:04 PM jepler: wow the main website transfers a LOT of data. The average over the past 216 days is 126.35GB/day.
12:09 PM seb_kuzminsky: that's a surprisingly large number
12:09 PM seb_kuzminsky: huh, there are 62 unique committers in master since 2.8.0-pre1
12:09 PM seb_kuzminsky: that's also a surprisingly large number
12:10 PM jepler: somehow, according to this log analyzer, 25318 requests of size 0 accounted for 77.35% of all transfers by bytes
12:11 PM jepler: https://emergent.unpythonic.net/files/sandbox/longterm.html
12:11 PM jepler: but I also "manually" (via sed script) counted 5 one-day logs and got a similar daily value
12:12 PM seb_kuzminsky: i wonder what those 12 million 404s were asking for
12:15 PM rene-dev: is it possible to set the current tool from a m6 remap?
12:16 PM rene-dev: to me it looks like there is a bit of stuff broken in remaps in master...
12:16 PM rene-dev: im having a hard time to get the abort to work properly, and setting the correct tool
12:16 PM seb_kuzminsky: i wouldn't be surprised if there are bugs lurking in remap
12:17 PM seb_kuzminsky: but i haven't looked closely at it, so it's just superstition on my part
12:17 PM rene-dev: so I have a remap that does the toolchange.
12:17 PM seb_kuzminsky: cool
12:17 PM rene-dev: if it goes wrong, it doesnt abort, it always continues, even though it should abort in the epilog
12:17 PM rene-dev: and I dont think you need an prolog or epilog for a m6 remap anyway
12:18 PM rene-dev: and it always sets the new tool. if there is a problem, I want to set the tool to T0, or the old tool, depending on what happend
12:19 PM seb_kuzminsky: that seems like good behavior on failure
12:19 PM rene-dev: yeah, because you always know if the problem occured on place or pickup move
12:20 PM rene-dev: and under no circumstances should it continue with whatever is left in the spindle...
12:20 PM rene-dev: maybe iocontrol is the problem? I have looped the pins. without looping them it gets stuck on the m6
12:21 PM rene-dev: also, I cant get it to print any messages from within a remap, which doesnt make debugging easier
12:21 PM seb_kuzminsky: normally the IO pins would poke the hardware of the tool changer to do the actual move
12:21 PM rene-dev: yes, but that isnt possible.
12:22 PM seb_kuzminsky: right, because you're doing the work in a remap function now... are you even sending the tool change command to io at all any more?
12:22 PM rene-dev: the toolchanger carousel is set up as a axis, and picking and placing is done with notmal movements
12:23 PM rene-dev: yes, all stock, running master, not my modified stuff that is still work in progress.
12:24 PM rene-dev: what norbert does, is he connects the iocontrol pins to motion analog and digital io, so he can set and read them from gcode.
12:24 PM rene-dev: that seems to work, but is a really really bad solution in my opinion...
12:28 PM rene-dev: https://github.com/LinuxCNC/linuxcnc/blob/8ca6b52ebe6fc451762f0f06c08a266944f978ea/src/emc/task/emccanon.cc#L1976-L1982
12:28 PM rene-dev: "we really want a configurable chain of events to happen when a tool change is called for."
12:29 PM seb_kuzminsky: yep
12:30 PM rene-dev: I lookes at how its done on other controls. they usually only have a macro, that by default does nothing, but set the tool number.
12:30 PM rene-dev: and if you need that on IOs, or in our case hal, you can do that.
12:33 PM rene-dev: http://linuxcnc.org/docs/html/remap/remap.html#_understanding_the_role_of_iocontrol_with_remapped_tool_change_codes
12:35 PM rene-dev: so I get the tool/pocket number from those sources:
12:35 PM rene-dev: 1. analog pin
12:35 PM rene-dev: 2. variable set by prolog
12:35 PM rene-dev: 3. #<_current_tool>
12:36 PM rene-dev: I dont really understand why you need the analog pins in a remap, or the prolog, when you have #<_current_tool>
12:36 PM seb_kuzminsky: i would think, to pass it to some toolchanger component in hal, that doesn't have access to the interp variables
12:37 PM rene-dev: yeah, I get that _some_ toolchangers can work from only the hal pins
12:38 PM rene-dev: but with the normal iocontrol pins, a toolchange cant even fail.
12:38 PM seb_kuzminsky: for toolchangers implemented by Tx/M6/M61 remap it's not needed
12:38 PM seb_kuzminsky: yeah, that's sure a shortcoming of the current implementation
12:39 PM rene-dev: yes, I know. but its still there, and in the way. because without the pins it gets stuck, and with the loop, it sort of overwrites what I do in the remap
12:39 PM rene-dev: at least that is what I think is happening
12:40 PM seb_kuzminsky: does your M6 remap call the built-in M6 at the end?
12:40 PM seb_kuzminsky: *something* must be telling IO to do the tool change pin handshale
12:40 PM seb_kuzminsky: *handshake
12:42 PM pcw_mesa: seb_kuzminsky: will send your 7I64s back today
12:42 PM seb_kuzminsky: thanks
12:42 PM rene-dev: I think it does. but I cant figure out how to fail, or how not to set the new tool, but t0 or the old tool...
12:43 PM seb_kuzminsky: did they work right after a firmware update?
12:43 PM rene-dev: I could use M61, but not sure if thats the way to go
12:44 PM pcw_mesa: Yeah, they were so old that they did not have a unit number so when SSLBP firmwar easked for a unit number it got a blank stare
12:44 PM seb_kuzminsky: oh good
12:44 PM seb_kuzminsky: rene-dev: m61 is like 5 lines in interp
12:48 PM seb_kuzminsky: is this toolchange rework part of the tooltable api you're working on?
12:49 PM rene-dev: I decided to do 2 things: first I will fix the bugs in the current implementation
12:49 PM seb_kuzminsky: awesome, thank you
12:50 PM rene-dev: because now I know every part that touches tools in linuxcnc...
12:50 PM rene-dev: and then I will finish the rework, which will have a clean api, which then could easily be replaced by a different storage backend
12:50 PM seb_kuzminsky: there's a lot of code to grok, a lot of moving pieces that have to mesh just right
12:51 PM rene-dev: and also clean up iocontrol, but I really dont want to change too much without talking to you guys
12:52 PM seb_kuzminsky: thanks, that work flow makes it better for everyone i think
12:52 PM seb_kuzminsky: bbl, lunch
01:46 PM jepler: seb_kuzminsky: today, the top 404s are "my misconfigured apple product always fetches /apple-touch-icon-precomposed.png" and "my apt thinks these files might exist" like /dists/wheezy/base/i18n/Translation-en.xz
01:51 PM mozmck: jepler: cncnoob1979 emailed me back and says: "After the last server upgrade I no longer get the "edit" for any post other than the last post that I create. I can see the edit menu only when it's the last post/reply. If it's a previous post that has a reply after it, I can not edit that previous post."
01:52 PM mozmck: I looked and was unable to see any setting that looked like it would do that. Any idea?
01:55 PM jepler: mozmck: I think you asked about this before, or else some other user also reported it. I looked and didn't find anything relevant.
01:56 PM jepler: though the bit about whether it's the last post in a thread or not seems like new and relevant info
01:56 PM mozmck: Yeah, I asked for the same user. This is just a little more information on the subject.
01:57 PM jepler: so, yes, this is a bug they added to kunena
01:58 PM jepler: see e.g., https://www.kunena.org/forum/k5-0-support-archive/150584-edit-post-problem#198053 and the threads it links to
02:01 PM mozmck: huh, new and improved!
02:02 PM mozmck: last post here says it will be fixed in 5.1 https://www.kunena.org/forum/general-questions-and-how-tos/150547-registered-users-can-t-edit-own-posts-any-longer
02:02 PM jepler: yeah I saw that
02:03 PM jepler: on 2018-03-01, 98GB of "linuxcnc-2.7-wheezy.iso" were downloaded
02:03 PM mozmck: And this link has a message.php file that fixes it apparently https://www.kunena.org/forum/k5-0-support/150456-editing-posts#197805
02:04 PM mozmck: I wonder how hard it is to set up a torrent for the iso?
02:09 PM jepler: https://emergent.unpythonic.net/files/sandbox/access-by-byte-size-20180301.txt
02:12 PM jepler: 367 accesses to that iso were by the same IP address, but it appears that they were using a downloader which requests many individual chunks. Each request is a little over 1MiB, which means they didn't even manage to download it all I don't think.
02:15 PM jepler: 115 distinct IP addresses from 115 distinct "Class C" networks, so ... assuming those all represent different people, they didn't even all manage to get a full download
02:17 PM jepler: it's crazy to imagine hundreds of people a week download the software I work on as a hobby
02:19 PM seb_kuzminsky: jepler: wait, do you mean 100ish downloads of the debs per week?
02:19 PM seb_kuzminsky: today's full of surprises, if so
02:20 PM andypugh: I am having a problem connecting a 7i80DB
02:20 PM andypugh: hm2_eth says “These instructions assume your dedicated network interface is "eth1", 192.168.1/24 is an unused private network"
02:20 PM andypugh: But my network port seems to be called eno2, not eth1
02:21 PM andypugh: Does anyone know if the “eth1” part is configurable?
02:22 PM seb_kuzminsky: oh hey, the buildbot download counter thingy is still working: http://buildbot.linuxcnc.org/~seb/billions-served/
02:23 PM andypugh: Those are big numbers for a niche way to get the software
02:23 PM seb_kuzminsky: andypugh: i dont think the name of the interface matters to hm2_eth
02:24 PM seb_kuzminsky: the hm2_eth manpage just tries to help you turn off irq coalescing
02:24 PM andypugh: Hmm, OK
02:26 PM andypugh: maybe I need to change the edit etc/network/interfaces to suit eno2 instead?
02:26 PM andypugh: (I also can’t connect to WiFi with this machine, which is annoying. It can find the network but just keeps on asking for the password repeatedly)
02:27 PM andypugh: Makes viewing the docs tricky
02:37 PM andypugh: This is why I always hesitate to recommend the Mesa ethernet cards to people, I always really struggle to get them to work
02:38 PM jepler: we *could* pull more of the setup & teardown into hm2-eth, always at the risk of causing more problems than we solve
02:39 PM jepler: for instance, we could call out to 'ethtool' manually to set the coalesce value to 0
02:39 PM jepler: (apparently, I didn't try it)
02:39 PM jepler: and of course a user who is wired differently could use the point and click gui to set the static IP address
02:39 PM jepler: haha wired
02:40 PM mozmck: That is a bit risky! I have found that turning off irq coalescing is not benign on marvell or broadcom chipsets.
02:41 PM mozmck: Made latency a lot worse on both. I don't know if *all* broadcom and marvel chipsets are that way, but the ones I happen to have are.
02:43 PM andypugh: I have had a somewhat cryptic error a few times, but seem to be “in” now. For reference the error is “iptables: no chain/target/match by that name”
02:44 PM andypugh: My problem was first using the wrong adapter name in the network/interfaces file, and then miss-typing is when I did put the right one in. Doh!
02:50 PM mozmck: I have a script we use to set up an ethernet port with a 7i92 attached and powered on. It was written by a newbie at shell scripts and modified by myself a little (and I'm not much better), and is probably ugly enough to make seb curl up and cry.
02:51 PM mozmck: I'll share it if it could useful, but would appreciate tips or cleanup :-)
02:53 PM jepler: shell scripts are like onions that way
02:54 PM jepler: there are layers and layers, and some people even cry when you try to slice through them
02:55 PM pcw_mesa: I have never gotten Broadcom Ethernet chips to work well for real time
02:55 PM pcw_mesa: easy enough o verify just with erratic ping times
02:57 PM pcw_mesa: luckily they are fairly rare (Realtek and Intel have the bulk of the market and they both work)
02:58 PM pcw_mesa: AFAIK the RTK driver has no IRQ coalesce option and it always helps with newer intel (not sure if 100BT intel has the option)
02:59 PM pcw_mesa: Andy , I usually just use the network mangler to set things up
03:01 PM mozmck: pcw_mesa: we were testing some Dell computers with broadcom ethernet chips, and at least running latency-histogram the latencies were pretty bad until I removed the hardware-irq-coalesce-rx-usecs 0 setting from the interfaces file.
03:01 PM mozmck: After that they seemed to work pretty well.
03:02 PM pcw_mesa: strange...
03:02 PM mozmck: Yeah, I had found that with a Marvell chip in a Lenovo desktop a while back as well.
03:03 PM pcw_mesa: wonder if the driver is broken
03:05 PM pcw_mesa: Ive wondered if the servo thread rate can be slowed for machines with bad latency For example my BXBT1900 has bad latency if you enable the built in WIFI
03:05 PM pcw_mesa: but works fine at 500 Hz
03:06 PM pcw_mesa: AFAIK there are two main effects of slowing the servo thread rate for velocity mode servos/stepgens
03:07 PM mozmck: Yeah, we got some J1900 computers with built in wifi, and I had to blacklist the wifi driver to get good latency.
03:08 PM pcw_mesa: one is the somewhat lumpier acceleration because of fewer velocity steps
03:08 PM pcw_mesa: the other is the chord error when you have curves
03:09 PM mozmck: chord error - as in you get sections of straight lines instead of a smoother curve?
03:10 PM pcw_mesa: Yes, easiest to describe for circles (max error distance from polygon to circle)
03:12 PM mozmck: pcw_mesa: I discovered that some of the J1900 freezes we have seen are common to all baytrail cpus, and the fix/workaround is to set intel_idle.max_cstate=1 on the kernel command line.
03:12 PM mozmck: pcw_mesa: https://bugzilla.kernel.org/show_bug.cgi?id=109051
03:14 PM rene-dev: andypugh: hmm, I never had a problem like that. just bind one interface to dhcp, and the other to a fixed ip.
03:14 PM pcw_mesa: chord error its pretty small (worst case is fastest circle) error is r - r cos(a/2) where a is angle between polygon vertices and r is radius of fastest circle (a=v^2/r)
03:15 PM rene-dev: pcw_mesa: I have a very strange problem with a 7i92+7i76+7i74
03:15 PM pcw_mesa: (inscribed polygon)
03:16 PM andypugh: I figured out the 7i80. (might be worth a note in the hm2_eth docs that you can find the name of the adaptor with “ip link show” as there seems to be a policy to move towards predictable interface names. (for example my wlan0 is actually called wxgibberish which I think is the USB ID or something. Which is actually a pretty decent idea.
03:16 PM rene-dev: on the 7i74 there are 3 stmbl, and one of them always reports crc error on the port.
03:16 PM pcw_mesa: one channel?
03:18 PM rene-dev: yes, the stmbl says it got a wrong crc in the request. exactly the same setup worked a log time with 5i25. I just replaced the 5i25 with 7i92
03:18 PM rene-dev: but only one, no matter what port I plug it into. already changed the cable, and the stmbl.
03:19 PM rene-dev: ah, I also updated linuxcnc. I wonder if thats related?
03:19 PM rene-dev: I mean related to that race bug... can the fpga ever send out packages with a wrong crc?
03:20 PM pcw_mesa: I dont think so
03:22 PM rene-dev: maybe when the driver writes, while its sending, and after the crc calculation?
03:23 PM andypugh: I think we need to fix the race and re-examins things
03:23 PM pcw_mesa: the SSLBP code copies data from the registers to local ram first so you might get bad data but the CRC calc is done at the send char level
03:23 PM andypugh: (Jasen also reports that setting scales is a bit random, some STMBLs get it, some don’t, apparently)
03:24 PM rene-dev: I never really tried that with more than one drive
03:24 PM rene-dev: ah, ok
03:24 PM rene-dev: whats the correct behavior as a slave when I get a wrong crc? not reply?
03:25 PM pcw_mesa: parameter setting coule difinatel be broken by a race
03:25 PM pcw_mesa: could definately
03:26 PM pcw_mesa: thats what our slave do (no reply and set the error flag)
03:27 PM rene-dev: in the fault byte of the next transfer?
03:28 PM rene-dev: is that sticky, or do I clear that after I transmit it once?
03:30 PM rene-dev: now downgrading linuxcnc, because thats the only thing that changed, apart from 5i25->7i92
03:30 PM pcw_mesa: I'm not sure, I need to look
03:31 PM rene-dev: its got to be reset at some point
03:35 PM rene-dev: im using more process data, so always use all 3 registers. I guess Im much more likeley to see problems then.
03:35 PM rene-dev: expecially the floats are sensitive to partial transfer...
03:39 PM rene-dev: it seems to be happening less often before andypugh s param commit
03:40 PM andypugh: But that makes no sense (he wails)
03:40 PM rene-dev: I know :D
03:41 PM andypugh: One thought, perhaps param setting is leaving junk in the registers?
03:41 PM rene-dev: maybe the lcd board doesnt check the crc properly?
03:41 PM andypugh: All the registers are written every time?
03:41 PM rene-dev: the stmbl sees a crc error when this happens
03:42 PM rene-dev: but pcw_mesa says its impossible that the fpga sends a request with bad crc
03:43 PM andypugh: And I think it is impossible that the param setting stuff can affect process data. So the users must be lying to us.
03:43 PM andypugh: :-)
03:43 PM rene-dev: so do I
03:44 PM rene-dev: there is something going on
03:45 PM rene-dev: I swapped all the parts, including all the cables. always crc error after a while, on one drive
03:45 PM rene-dev: and it worked a long time with the 5i25...
03:48 PM rene-dev: changing the order doesnt help
03:51 PM rene-dev: mesaflash reports no errors in the lbp16 control/status space
03:59 PM pcw_mesa: Just checked 7i92 with 7I76_7I74D firmware running 4x 7I73s and 1 7I90 2.7.12 seems OK
04:00 PM pcw_mesa: (all on 7I74)
04:03 PM pcw_mesa: 2.7 does have the bug that it wont find non-sequential ssremotes (at least on sserial port 1)
04:03 PM pcw_mesa: pretty sure that was fixed in master
04:08 PM andypugh: If I hadn’t configured my ethernet port to connect the 7i80 I could probably download a firmware for the 7i80 that I could start debugging with
04:08 PM andypugh: (All this time I have been trying to get the WiFi dongle to connect, it can see the network but won’t authenticate)
04:09 PM pcw_mesa: a usb-ethernet dongle is one solution
04:09 PM rene-dev: a dual ethernet board is another ;D
04:12 PM rene-dev: pcw_mesa: do the 7i73
04:13 PM rene-dev: how many bytes of process data does the 7i73 use?
04:15 PM rene-dev: define working fine... do you see problems on the lcd? :D
04:16 PM pcw_mesa: i am not running a LCD is definitely being sent bad data from linuxcnc in 2.8
04:17 PM pcw_mesa: (the 'f's)
04:17 PM pcw_mesa: and according to mike, runs fine with 2.7
04:18 PM pcw_mesa: what I am checking is your 7I92/7I76+7I74 config with multilple remotes
04:19 PM pcw_mesa: and its been running here with 5 remotes for about 1/2 hour with no errors
04:19 PM rene-dev: with master?
04:19 PM pcw_mesa: ( no, with 2.7.12 )
04:19 PM rene-dev: ah
04:20 PM rene-dev: I cant try 2.7
04:21 PM pcw_mesa: I cant try 2.8 easily on this machine, have to move to another to try master (this is a default stretch test ISO)
04:22 PM pcw_mesa: i will try 2.8 over the weekend
04:23 PM rene-dev: ok, thanks... I dont think there is much difference in the hm2/sserial stuff from 2.7 to master
04:26 PM andypugh: What tools do you use to analyse the tcp dumps?
04:26 PM rene-dev: I dont
04:26 PM pcw_mesa: there is mikes scrambled LCD (works on 2.7 broken on 2.8) but I dont think anyone has bisected it
04:28 PM rene-dev: the stuff from the issue comes from my virtual mesa card, with a virtual stmbl
04:28 PM pcw_mesa: I can read LBP16 from staring at it for too long :-)
04:28 PM rene-dev: https://gist.github.com/rene-dev/dfc771f7669b36e6e57a71ad258a4ee1
04:28 PM Tom_L: andypugh would wireshark capture what you're after?
04:28 PM rene-dev: might help you with debugging
04:29 PM rene-dev: it printfs the lbp16 commands
04:29 PM rene-dev: BTW, I have a complaint about the driver, it doesnt work with a mesa card running on 127.0.0.1 :D
04:30 PM rene-dev: you could also make that into a wireshark decoder
04:30 PM pcw_mesa: but the ping times are good :-)
04:31 PM rene-dev: I cant remember what it was, but I think it gets confused when it tried to do stuff to the loopback interface
04:32 PM jepler: I know it's apropos of nothing, but I just got a "circuitpython" board and wow! For under $10, you get a board that runs a dialect of Python, including a proper python repl on USB-serial. It also acts like a USB drive, just edit 'main.py' in your favorite text editor; the program restarts whenever you save the file. (Specifically, the board is a 'Trinket M0' from adafruit.com)
04:32 PM rene-dev: the ping time might be good, but you often get timeouts, especially when printfing a lot
04:33 PM jepler: ATSAMD21 @ 48MHz
04:33 PM rene-dev: I hate the SAMs, they are slow and expensive :)
04:33 PM jepler: rene-dev: ouch, yes, probably you can get a very broken system, because it'll try to firewall all programs but rtapi_app from talking on that device
04:33 PM jepler: and maybe the ARP stuff doesn't work right either
04:34 PM jepler: patches to fix it are welcome
04:34 PM jepler: rene-dev: adafruit has several circuitpython models, I picked this one based solely on price, not performance
04:35 PM jepler: >>> 1 << 29
04:35 PM jepler: 536870912
04:35 PM jepler: >>> 1 << 30
04:35 PM jepler: OverflowError: small int overflow
04:35 PM jepler: >>> 1e38, 1e39
04:35 PM jepler: (1e+38, inf)
04:35 PM rene-dev: for test stuff it would be good to disable that
04:36 PM jepler: rene-dev: the easiest patch to accept would probably be a new loadrt parameter to just disable whatever parts are problematic
04:36 PM rene-dev: yep
04:37 PM rene-dev: I found that its no problem to run linuxcnc in virtualbox, and have the mesa card somewhere on the network
04:37 PM jepler: possibly: do_arp=0 do_iptables=0 assuming those describe what you have to turn off
04:37 PM rene-dev: I just wouldnt run a machine that way :D
04:37 PM rene-dev: but for testing its ok
04:39 PM jepler: huh that's weird FP rounding too
04:39 PM jepler: >>> for i in range(22, 26): print(i, (2. ** i - 1) - 2. ** i)
04:39 PM jepler: ...
04:39 PM jepler: 22 -1.0
04:39 PM jepler: 23 -2.0
04:39 PM jepler: 24 -4.0
04:39 PM jepler: 25 0.0
04:39 PM rene-dev: that cpu has no fpu, so you are looking at soft floats, no idea which implementation it uses...
04:40 PM pcw_mesa: I'm somewhat amazed that tcpdump gets every packet and doesn't interfere with timing
04:40 PM jepler: not quite IEEE single precision, the rounding is wrong
04:40 PM jepler: pcw_mesa: yeah it's quite convenient!
04:40 PM rene-dev: its not really a lot of data, is it?
04:41 PM rene-dev: did you ever work out the bandwidth?
04:41 PM jepler: >>> -0.0
04:41 PM jepler: -0.0
04:41 PM jepler: >>> -0.0+0.0
04:41 PM jepler: 0.0
04:41 PM jepler: but they got the two details about negative zero right that were bothering me at $DAY_JOB today so that's nice
04:42 PM pcw_mesa: no its not a lot of data but still nice it doesnt muck with the timing
04:42 PM rene-dev: 104 bytes per cycle on my test, 100kb/s is nothing for ethernet :D
04:43 PM pcw_mesa: It would be nice if the stepgen had +- 0 velocity
04:46 PM pcw_mesa: So the rest step/dir state didn't change depending on dir
04:47 PM mozmck: Is that in the driver or fpga firmware?
04:47 PM rene-dev: whats the deal anyway with configs now using the hal pid instead of the one in hostmot? why is that?
04:48 PM pcw_mesa: Bugs in the stepgen driver plus you can get better performance from PID
04:49 PM rene-dev: then why not remove the other one, or fix the bugs?
04:50 PM rene-dev: what are they?
04:50 PM pcw_mesa: mozmck: you would have to use sign-magnitude numbers at the FPGA interface (and patch inside the firmware)
04:50 PM pcw_mesa: (and patch the driver to use sign magnitude)
04:52 PM pcw_mesa: the position mode stepgen bug is mainly that its fragile and does not tolerate jitter well
04:52 PM pcw_mesa: (it can go off the deep end id the servo thread jitter is significant)
04:54 PM rene-dev: because its not scaled to the real period?
04:54 PM pcw_mesa: Ideally the position mode stepgen should be implemented with embedded PID and do all the "headroom" calculations internally to simplify the hal interface
04:55 PM rene-dev: yeah, I would prefer that. if its accessible pepile start to fiddle with it, and will make it worse
04:55 PM rene-dev: because it doesnt ever need real tuning
04:55 PM pcw_mesa: well FF2 needs tuning
04:56 PM pcw_mesa: but that could possibly be automated
04:57 PM pcw_mesa: especially if I add DPLL posted writes to the velocity register
04:57 PM rene-dev: does it really?
04:58 PM pcw_mesa: ( FF2 should be set to the number of seconds between position read and velocity write )
04:59 PM rene-dev: you are one of the few pepole that understand that in control theory it matters when you read your inputs, and set your outputs :)
04:59 PM pcw_mesa: bang your head against it enough, some sinks in
05:00 PM rene-dev: I actually worked with pepole who thought that it would be a good idea to have a current pid running faster than pwm, but on most micros the pwm comperator register is a shadow register, and only updated on overflow
05:01 PM rene-dev: even if not, it would not be pwm, but direct torque control, which comes with its own problems
05:03 PM pcw_mesa: yeah Ive also had people say you need a much faster velocity control loop and ignore the 20 KHz asynchronous PWM in the drive
05:04 PM pcw_mesa: at one time we considered phase locking the PWM to the external update data
05:09 PM rene-dev: we phase lock the 2 CPUs in the stmbl, but only to make the communication easier
05:11 PM rene-dev: but yes, I had pepole sugget to sync the pwm of all drives...
05:12 PM pcw_mesa: sync with a 360/N stagger...
05:15 PM KimK: mozmck: Let me know if this torrent works for you. Reports from others helpful also. I will support this torrent until it's replaced. Torrent help from others much appreciated. (If it helps, I'm currently using Deluge, which Mint has switched to lately, but I have previously used Transmission with good results.) http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Torrent
05:36 PM mozmck: KimK: using Transmission in Mint 17.3, I get this error: Tracker gave an error: "unregistered torrent pass"
05:37 PM mozmck: Huh, now it's downloading (very slowly!) it looks like. At first it wasn't.
05:39 PM mozmck: only 154 days remaining...
05:41 PM KimK: mozmck: Thanks for looking at it. It shouldn't be that slow, I must have it set up wrong, probably the tracker. Although I do have Deluge running in the background, so I have bandwidth limiting on. I think UL is 100K bps and DL is 200K bps. I'll look at it more later tonight, and maybe post a retry. Thanks again for testing!
05:43 PM mozmck: Ok, thanks for looking at that. I know the distributions have torrents for downloading iso's but I don't know exactly how all that works. Are there sites that will host iso's as peers for torrent downloads?
05:47 PM seb_kuzminsky: mozmck: no, all the peers in the torrent cloud collaborate on hosting the iso for new peers that join
05:47 PM seb_kuzminsky: that's why you should "seed" your torrents for as long as you want to help out new peers that join
05:50 PM mozmck: Yeah, but a bunch of someones obviously become peers on distro ISOs Is it all just by chance hoping people become peers?
05:59 PM seb_kuzminsky: people choose individually whether to shut down their torrent client or keep it up and keep seeding, yeah
10:16 PM jepler: my client also reports "unregistered torrent pass"
10:51 PM seb_kuzminsky: my client says it's downloading at 72 kB/s, but that it's not connected to any peers
10:51 PM * seb_kuzminsky is confused
10:51 PM seb_kuzminsky: must be time for bed