#linuxcnc-devel Logs

Mar 03 2018

08:05 AM jepler: my client never uploaded anything (I had primed it with a copy of the .iso, so it had nothing to download)
12:49 PM andypugh: pcw_home: Do you know if there is a firmware that will run at least one channel of a 7i74 from an 7i80DB-16 ?
12:49 PM andypugh: I thought that I might be able to use the 7i76 one, but the pins are laid out wrong.
12:50 PM pcw_home: let me take a look
12:51 PM pcw_home: do you have a -16 or -25 card?
12:52 PM andypugh: It’s a 16
12:52 PM andypugh: Though I have just realised that I can use an actual 7i76
12:53 PM andypugh: (and, in fact, just hooked up the 7i73)
12:53 PM andypugh: So I think I am OK to check the LCD bug, but not the parameter writes to multiple devices (alleged) bug
12:53 PM pcw_home: Yeah I thin the 7I74X4 config woudl not fit in a -16 And I didnt make a 7I74X3 for the -16 card
12:54 PM andypugh: So don’t bother making a bitfile, but if one happens to exist, it would be neater
12:55 PM andypugh: I think I can use the 5i25 for the parameter thing
12:55 PM pcw_home: Ill make you a 7I76+7I74x2 config
12:56 PM rene-dev: pcw_mesa I could not figure out what that crc error was. but eventually after swapping everything it went away. could not get it do do that again...
01:03 PM pcw_home: Yeah I ran a 7i92, 7I76_7I74 config and 6 sserial remotes for a couple hours with no errors
01:03 PM pcw_home: (when I first tried it I got all kinds of errors but it was a broken wire in my flat cable...
01:08 PM pcw_home: we had one customer then might have been affected by the race bug ( random analog out spikes from 7I77 on one channel )
01:09 PM pcw_home: that sounds like the kind of issue you would get with non-atomically updated >byte size data
01:12 PM rene-dev: yes, I guess I had a similar problem.
01:13 PM rene-dev: yes, but I guess with analog servos, a spike in one cycle only you dont even notice
01:13 PM rene-dev: or did that happen repeatedly?
01:14 PM pcw_home: every few minutes (of course size is very data dependent and data is pretty random on the feedback)
01:14 PM pcw_home: spike size I mean
01:15 PM rene-dev: yep... what erer the implications so he noticed the problem?
01:15 PM pcw_home: a big 1 ms spike is pretty noticeable
01:16 PM pcw_home: TIC!
01:17 PM rene-dev: depending on the amp, it could just make a noise, or go straight into following error, thats why im asking
01:17 PM rene-dev: how did you fix it?
01:18 PM pcw_home: Yeah, the only one channel thing sounded very much like a race condition
01:18 PM rene-dev: does that go away when you swap the tram order?
01:19 PM pcw_home: Not tried yet (I could not duplicate it but of course a a race is very data size / PCI speed dependent)
01:20 PM pcw_home: (this was PCI) but the issue is higher up the pipe so I assume PCI has the same issue as Ethernet
01:21 PM rene-dev: yeah, it must be right on the edge. but most of the slaves are probably not affected, as they are only IOs
01:22 PM rene-dev: but thats still a different issue form those wrong bits in the lcd stuff
01:23 PM pcw_home: yeah that a 2.7/2.8 issue and not sure where
01:39 PM pcw_home: the other thing weird in Mikes LCD stream are occasional clear screen commands (you would think you would only do that once)
01:45 PM andypugh: Well, I set up a 7i80, 7i73 and an LCD, and it works perfectly with 2.7 _and_ with 2.8
01:45 PM pcw_home: andy I'm compiling your 7I76+7I74x2 but its slow since its close to full on a -16 part (and this is an ancient PC)
01:46 PM andypugh: Thanks.
01:46 PM andypugh: Maybe it is channel-dependent or something crazy
01:46 PM pcw_home: do you have mikes hal file? (the a,b,c,d display)
01:46 PM andypugh: At least I should be able to sort out the write order, that does appear to be a bug.
01:47 PM andypugh: I am using Mike’s real display file, but I can easily try the other.
01:47 PM pcw_home: he had a 7I76E which should be identical channel wise to a 7I80 --> 7I76
01:47 PM andypugh: (Though not having internet on the machine in question is a pain)
01:48 PM pcw_home: the WIFI hardware is funny?
01:51 PM pcw_home: USB --> Ethernet dongle FTW
01:51 PM andypugh: Apparently its tricky with PREEMPT_RT
01:53 PM rene-dev: not really. you can also just plug the card in your switch. then you only dont have internet while linuxcnc is running :D
01:53 PM rene-dev: but its probably not the best idea for what you are doing now :D
01:56 PM rene-dev: a friend just got the nvidia driver working with PREEMPT_RT. they have a usecase which involves deep learning stuff with a realtime backend :D
01:57 PM rene-dev: turns out, you can even deploy stuff with docker and still have it running in realtime :D
02:15 PM memfrob: Speaking of PREEMPT_RT... RTAI is coming along nicely xD
02:16 PM memfrob: I'm interested to see how Ryzen's SenseMI with it's neural net branch prediction pans out with it.
02:18 PM memfrob: Someone on the mailing list tried getting it going on 4.9, I told him to backport the Ryzen topology patches from 4.10 but he completely ignored my advice.
02:20 PM memfrob: Not sure why you would even bother trying to get it working on a pre-Ryzen supported kernel, but hey, what do I know. I've just been doing real-time kernel development for the past 6 years!
02:23 PM pcw_home: andypugh: http://freeby.mesanet.com/7i80db_16_7i76x1_7i74x1D.bit (had to start over since one with 2X 7I74s would not fit)
02:25 PM andypugh: Thanks PCW
02:36 PM rene-dev: memfrob: why bother with rtai? In my opinion rt preemt is better in every way
02:39 PM memfrob: If you don't need super low latency. The numbers I get on my end are trash.
02:41 PM memfrob: Using musl and applying -Os CFLAGS across the entire Linux system helped a bit. make tinyconfig..
02:43 PM memfrob: Not every system is using an Intel Atom CPU. RTAI runs great on everything.
02:49 PM rene-dev: but it cant talk to ethernet hardware, which is in my opinion the only interface you want.
02:52 PM rene-dev: it supports long and small cables, its isolated, robust, really easy and cheap to interface, and unlike pci or parport it will still be around for the next 10+ years
02:53 PM memfrob: What in god's name is wrong with PCI E external FPGA?
02:54 PM memfrob: Mesa cards are boss!
02:55 PM memfrob: pcw_home, didn't you design those?
02:55 PM rene-dev: I guess he did :D
02:58 PM rene-dev: pcie is not really easy/cheap to interface to a fpga directly. thats why the pcie mesa cards use the pcie to pci bridge. pci is almost dead on newer hardware.
02:59 PM rene-dev: then there is the isolation problem, and the big connector. I dont like that. ethernet solves all of that in a very nice way.
02:59 PM pcw_home: Ethernet is more CPU agnostic
03:00 PM pcw_home: USB-C may revive external PCIE hard to tell
03:00 PM rene-dev: you could probably easily build a usb-c mesa card
03:00 PM sync: well, the subset of usb that uses usb-c as a connector
03:01 PM rene-dev: yeah. and you could even support power delivery both ways ;D
03:01 PM sync: and you get the added benefit of >40M firmware updates for your thunderbolt controller
03:02 PM sync: and 4MB updates for your USB-PD controller
03:02 PM pcw_home: no TB thanks
03:02 PM rene-dev: and firmware updates for the cable!
03:02 PM sync: yes
03:03 PM sync: and you can force the users to plug in the cable in the right way
03:03 PM sync: as the cable "knows" which way it is plugged in
03:03 PM rene-dev: oh, so you can have a trolling mode, where you always need to turn the cable 3 times
03:03 PM sync: yes
03:04 PM Tom_L: whoever invented the USB plug should be flipped over in his grave
03:05 PM memfrob: https://www.youtube.com/watch?v=811z3ktTh-U
03:05 PM rene-dev: you can probably run small machines form the powerdelivery
03:05 PM sync: pcw_home: you need TB iirc for the pcie lanes
03:06 PM pcw_home: Yeah so basically not interesting
03:06 PM sync: why?
03:07 PM sync: it is pretty great
03:07 PM pcw_home: for consumers maybe
03:09 PM sync: what is so bad about it from a developer prespective?
03:10 PM pcw_home: At least the last time I looked much was covered by NDAs so no good for open source
03:11 PM sync: well, you don't have to do much with it that way
03:11 PM sync: it just gives you a pcie port like you would expect
03:16 PM pcw_home: so at my end of the USB-C cable I have PCIE without any Thunderbird technology?
03:19 PM rene-dev: yes, you can buy a usb-c case with just a pcie slot. many pepole use them for external GPUs.
03:20 PM pcw_home: and most hosts support this?
03:21 PM rene-dev: thunderbold is just pcie + some management stuff + display port. you need to tell it to do pcie.
03:21 PM rene-dev: yes, no probem.
03:22 PM rene-dev: although the gpu will have the bandwidth limit of only 1x lane, or less, if you send the image back
03:22 PM pcw_home: So nothing on the GPU end to tell upstream its PCIE?
03:24 PM rene-dev: yeah, you need a controller that tells the host what to do.
03:24 PM pcw_home: cabled PCIE has some sideband reset/power control I would expect that would have to be duplicated using Thunderbird methods
03:24 PM rene-dev: as there are multiple modes, and the wires can be used for power, pcie, or displayport
03:24 PM pcw_home: I know that
03:25 PM rene-dev: but I still prefer ethernet, is just so much easier :D and you dont really need the bandwidth...
03:26 PM MarkusBec: there are some usb-c tunderbold to pcie chipsets
03:26 PM MarkusBec: i think its just pain if you want to implement it direkt in an fpga
03:26 PM pcw_home: right, thats what I was afraid of
03:26 PM MarkusBec: that is full of NDA
03:26 PM rene-dev: you cant do pcie directly in the cheap fpgas, too slow
03:27 PM MarkusBec: but i think tunderbold to pcie is a single chip solution
03:28 PM pcw_home: yeah thats the problem
03:28 PM pcw_home: unless you can get the chip specs without NDA
03:29 PM MarkusBec: https://www.mouser.de/ProductDetail/Intel/CV82524EFL-S-LJJY?qs=sGAEpiMZZMumM9SKmFWhKns403JJNFnyP%252byWFMq1RqU%3d
03:29 PM MarkusBec: hm single chip
03:29 PM MarkusBec: but no infos
03:30 PM pcw_home: yep
03:30 PM jepler: what even are these things? Must be reusing the USB3 connector for its twisted pairs, not the electrical interface. and yeah it has something to do with bitcoin https://www.aliexpress.com/store/product/0-6M-PCI-Express-PCI-E-1X-to-16X-Riser-Card-Adapter-PCIE-Extender-with-USB/
03:31 PM jepler: er link should be https://www.aliexpress.com/store/product/0-6M-PCI-Express-PCI-E-1X-to-16X-Riser-Card-Adapter-PCIE-Extender-with-USB/909573_32819930249.html I chooped a bit too much off
03:31 PM rene-dev: yes, they are just passive extensions. you can get them with usb or hdmi cables
03:31 PM sync: yeah it is just a riser card
03:31 PM MarkusBec: they just use the kable as a well specified cable that is cheap
03:31 PM sync: using usb3 or hdmi as high quality signal cable
03:31 PM jepler: > For old version, such as 006,007, sometimes it probebly cause short circuit. So we improved it based on the original version.
03:31 PM jepler: such confidence. so inspire.
03:32 PM rene-dev: do the linuxcnc tests break when you cancel them?
03:32 PM sync: jepler: they exist so you can use all your pcie ports with dual height gpus
03:32 PM jepler: rene-dev: sometimes you can leave things in a bad state. 'halcmd unload all', 'halcmd -R', 'halrun -U' are things to try then.
03:33 PM pcw_home: I suspect you could even use cat5/RJ45 (I know this works with re-drivers)
03:33 PM pcw_home: (for PCIE)
03:35 PM MarkusBec: pcw_home: maybe getting the datasheets with a john doe ltd?
03:35 PM rene-dev: jepler hmm, that didnt fix it
03:35 PM MarkusBec: :)
03:35 PM pcw_home: yeah...
03:35 PM rene-dev: suddenly many tests fail, with wired error messages
03:36 PM rene-dev: git says its reasonable clean, I already tried rebuilding
03:36 PM rene-dev: application-specific initialization failed: no display name and no $DISPLAY environment variable
03:36 PM rene-dev: is that normal?
03:37 PM jepler: that means the program is trying to display a window but can't.
03:37 PM rene-dev: ah! I started linuxcnc, and it cleared the lock
03:37 PM rene-dev: now it works
03:38 PM rene-dev: so yes, canceling tests is a bad idea
03:38 PM jepler: ah the DISPLAY variable is unset by the test runner specificially to avoid accidental dependency on showing display windows
03:39 PM rene-dev: norbert asked me if its possible to write tests for gmoccapy, can that just run without the display like this?
03:39 PM rene-dev: and then poke the hal pins...
03:42 PM andypugh: rene-dev: pcw_home: I have tried the “A|B|C|D” format string with LCD and it shows “f”. But it shows “f” in 2.7 and in 2.8, and I can see the 102 (ascii “f”) in the data stream from the LCD component, so it is a bug in the lcd component with short format strings, I think.
03:45 PM pcw_home: I also saw some "clear display" code in the middle of the Ethernet stream, is that expected?
03:57 PM rene-dev: great, now I have the tool number, tool pocket, realpocket, and fakepocket...
04:16 PM andypugh: It outputs a “clear screen” (0x1A) when the page is changed
04:16 PM andypugh: Though I am not sure that code works.
04:18 PM andypugh: The spurious “f” is an lcd.comp bug.
04:18 PM andypugh: I tried to fix a problem and got it wrong.
04:19 PM andypugh: https://github.com/LinuxCNC/linuxcnc/blob/2.7/src/hal/components/lcd.c#L282 should be a >=
04:20 PM andypugh: Otherwise it always prints an extra character. And the “f” just happens to be the next bit of memory after the end of the format.
04:20 PM andypugh: So _that_ is understood.
04:21 PM pcw_home: but you cannot duplicate his bug?
04:21 PM pcw_home: (Mike_Eitels bug)
04:21 PM andypugh: Well, there is something a bit wrong
04:22 PM andypugh: dancing characters.
04:22 PM andypugh: could be the out-of-place DoIt
04:22 PM andypugh: Need to try fixing that
04:22 PM andypugh: But I am certainly not seeing any difference between 2.7 and 2.8
04:23 PM andypugh: But maybe it is down to what character the compiler puts in the memory off the end of the LCD strings?
04:24 PM pcw_home: that might explain the 2.7/2.8 difference
04:46 PM pcw_home: so the clear screen commands are probably in response to Mike changing the display pages (with a button?) while logging
04:50 PM andypugh: Yes
04:54 PM pcw_home: the timings suggest that, random .1 to 1 second times between commands
05:22 PM rene-dev: im not sure I understand the need for GET_EXTERNAL_SELECTED_TOOL_SLOT
05:22 PM rene-dev: what other way is there of selecting a tool, but Tx?
05:28 PM Tom_L: is is used in tool prefetch?
05:31 PM Tom_L: to indicate what empty pocket is next?
05:34 PM rene-dev: yeah, I know. but why would the interpreter need to read that?
05:34 PM rene-dev: it gehts set by the interpreter
05:36 PM Tom_L: hard to say, that's 14 yr old code now
05:36 PM Tom_L: alot has happened...
05:38 PM rene-dev: yeah, im trying to clean it up and fix it
05:39 PM Tom_L: daunting task too
05:41 PM rene-dev: yes
06:00 PM jepler: rene-dev: imagine you're previewing gcode. The part program might be written without calling out a specific tool. I think in the current design, GET_EXTERNAL_SELECTED_TOOL_SLOT is what could potentially allow that to work. but I didn't check in depth.
06:01 PM jepler: (of course, preview is not particularly accurate about toolchanges anyway)
06:01 PM rene-dev: its terrible about that...
06:02 PM rene-dev: this is now the 3rd refactor Im doing, and its still hard :D
06:03 PM rene-dev: SELECT_POCKET(int slot, int tool) doesnt make sense. you cant select a pocket, only a tool, thats what T does.
06:03 PM rene-dev: same with CHANGE_TOOL(int slot) a toolchange never includes a tool, the tool needs to be set before that.
06:04 PM rene-dev: right now im _only_ trying to fix pocket numbers, nothing else
06:05 PM rene-dev: there needs to be a clear seperation, the interpreter only dealy with tools, and their offsets, not with pockets.
06:05 PM rene-dev: the toolchanger only cares about pockets
06:06 PM rene-dev: the slot in CHANGE_TOOL(int slot) isnt used by emccanon, only by saicanon. emccanon uses the precalled tool.
06:09 PM rene-dev: I dont think the preview needs to care about tools at all, because you are always looking at the control point of the tool, you dont care about the position. but you need that to check the limits...
06:09 PM rene-dev: all not easy...
06:10 PM rene-dev: sometimes in preview the backplot and the preview dont match up, due to this difference...
07:42 PM andypugh: pcw_home: I am starting to wonder if the LCD home cursor command (0x1E) might take more than 1mS to happen.
07:44 PM andypugh: The clear-screen command also seems a bit unreliable.
07:55 PM Tom_L: lcds are slow creatures
08:21 PM pcw_home: the LCD stream interface is buffered so as long as you dont stack up too many slow commands it should be OK
08:27 PM pcw_home: I almost guarantee that clear screen takes longer than a ms (but these should be infrequent)
08:42 PM andypugh: If you are displaying a single character then you send a clear-screen every 3mS
08:42 PM andypugh: (Or it was doing)
08:42 PM andypugh: No, wait, sorry, that’s wrong
08:43 PM andypugh: It was sending a home-cursor every few mS
08:43 PM andypugh: And that seemed to fill the buffer (it took 5 seconds to change page)
08:43 PM andypugh: I have changed to a 1B 3B 20 20 and things are now a lot more stable.
08:44 PM andypugh: (In fact I might have fixed the issue)
08:44 PM andypugh: But I can’t get it to clear the screen at start-up
08:45 PM andypugh: It clears OK when you change the page, but the same character sequence sent at the start does not wipe the display.
08:45 PM andypugh: But that’s a puzzle for tomorrow
09:04 PM pcw_home: "I have changed to a 1B 3B 20 20 and things are now a lot more stable."
09:05 PM pcw_home: I suspect this is just because you now are sending more characters
09:08 PM pcw_home: printing just one character per line and then using fancier commands like erase to EOL every few ms is probably too fast
09:09 PM pcw_home: ( the LCD character buffer is 1024 bytes so will handle brief bursts of slow ops but not continuously )
09:47 PM Tom_L: possible unexpected "Feature": G54-G59.3 are in a modal group. In axis, MDi G55 will show in the active Gcodes as G55. Running a program with G55 will switch to G55 for the program but the axis active Gcode will not update to reflect it.
09:48 PM Tom_L: haven't tested other GUI