Back
[01:56:27] <jmkasunich> SWPadnos: around?
[02:10:27] <SWPadnos> yep
[02:10:45] <jmkasunich> remember user classes 1-4, and module specs and such?
[02:10:49] <SWPadnos> but delayed, as you can see :)
[02:10:57] <SWPadnos> yep, more or less :)
[02:11:11] <jmkasunich> in the mood for a little (I hope) more on that topic?
[02:11:30] <SWPadnos> in a few minutes - I'm testing a new flash trigger, and want to finish that up
[02:11:35] <jmkasunich> ok
[02:11:50] <jmkasunich> ping when ready
[02:11:53] <SWPadnos> ok
[02:12:00] <jmkasunich> for your reading enjoyment:
[02:12:01] <jmkasunich> http://pastebin.ca/499462
[02:12:13] <jmkasunich> http://jmkasunich.dyndns.org/pics/FPGA_GPIO.png
[02:52:15] <SWPadnos> jmkasunich, ping
[02:52:25] <jmkasunich> pong
[02:52:32] <SWPadnos> ding ...
[02:52:42] <SWPadnos> ok, game over :)
[02:53:00] <jmkasunich> didja glance at the pic and words?
[02:53:12] <SWPadnos> yes on the pic, not yet on the words
[02:54:02] <SWPadnos> one question on the picture: why the inverter from the XOR output to the upper mux?
[02:54:19] <jmkasunich> for open collector, you enable the output when the data is low
[02:54:27] <SWPadnos> ah yes - ok
[02:55:02] <SWPadnos> that circuit could have a race conditoin between OE and data output
[02:55:39] <jmkasunich> probably not long enough to matter
[02:55:48] <jmkasunich> the FPGA is so fast compared to the pin buffers
[02:55:55] <SWPadnos> no - 3 delays max
[02:56:15] <SWPadnos> hmm. do you know the switching speed of the pins?
[02:56:33] <jmkasunich> I could choose to register out and oe right before the buffer too, that would be a change inside the pindriver module, not really relevant to the higher level stuff
[02:56:37] <jmkasunich> checking that delay now
[02:56:50] <SWPadnos> anyway - cross that bridge if there's a river underneath ...
[02:56:52] <SWPadnos> sure
[02:57:07] <jmkasunich> NET "IOBits<0>" LOC = "p96" | DRIVE = 24 | IOSTANDARD = LVTTL | SLEW = SLOW ;
[02:57:26] <jmkasunich> the SLEW = SLOW is good if you're driving a long ribbon cable
[02:57:33] <SWPadnos> whatever "slow" means :)
[02:57:37] <SWPadnos> yep
[02:57:40] <jmkasunich> slower than FAST
[02:57:58] <SWPadnos> in any case, it's likely longer than 3x(5 or 6 ns)
[02:58:25] <jmkasunich> more like 1x
[02:58:36] <jmkasunich> those three levels of logic will be in 1 LIT
[02:58:38] <jmkasunich> LUT
[02:58:56] <SWPadnos> ah - true
[02:59:01] <SWPadnos> 4 inputs
[02:59:31] <jmkasunich> I've written the VHDL for that, and just got done writing a generate loop that makes 72 of them
[02:59:45] <SWPadnos> cool
[02:59:49] <jmkasunich> note that I'm splitting "pin driver" from "GPIO"
[03:00:00] <SWPadnos> good to note
[03:00:35] <jmkasunich> now the words
[03:00:48] <jmkasunich> yesterday we were talking mostly about module spec
[03:00:56] <jmkasunich> (two days actually)
[03:01:00] <SWPadnos> right. what is the difference between BASEADDR and ADDR?
[03:01:11] <SWPadnos> it's not immediately clear to me from scanning the description
[03:01:13] <SWPadnos> heh
[03:01:36] <jmkasunich> baseaddr is "the address at which the driver accesses this module, relative to the beginning of the FPGA memory mapped window"
[03:02:01] <jmkasunich> addr is "the subset of the address bus that is routed into the module so it can decode its internal registers
[03:02:18] <SWPadnos> right - either ADDR or DECODE is used
[03:02:24] <jmkasunich> yep
[03:02:37] <SWPadnos> and DECODE is essentially the demuxed array of register selects?
[03:03:05] <jmkasunich> decode is essentially what you'd get if you sent ADDR thru a 74138 style chip
[03:03:13] <jmkasunich> (except active hi)
[03:03:57] <jmkasunich> inside the module, a register strobe is CS AND WR (or RD) AND DECODE(n)
[03:03:58] <SWPadnos> ok, so you either get the S0/1/../N lines or the Y0/1/.../2^N lines
[03:04:08] <SWPadnos> right
[03:04:36] <jmkasunich> unless the module actually has something in it that needs a numerical address (RAM for example), decode is more efficient
[03:04:37] <SWPadnos> (S and Y from the 74138 pin nomenclature)
[03:04:40] <SWPadnos> right
[03:05:26] <SWPadnos> and it seems that most modules would have 8 or less registers anyway, so even the extra routing needde shouldn't be a big deal
[03:05:34] <SWPadnos> needed
[03:06:10] <jmkasunich> yeah
[03:06:57] <jmkasunich> anyway, I think the 2nd paragraph (first long one) pretty well covers stuff we were happy with the other day
[03:07:13] <jmkasunich> the 2nd long paragraph touches on stuff that is less settled
[03:07:21] <SWPadnos> eyp - I'm looking through the specs, to make sure I understand what's been done
[03:07:23] <jmkasunich> lets skip it just a moment and look at the samples
[03:07:50] <jmkasunich> the syntax is only a proposal, it could be changed for either ease of human writing or ease of parsing
[03:08:16] <SWPadnos> do you expect the tool to automatically determine how many bits are needed for those variables (like step_type)?
[03:08:26] <SWPadnos> I'd say that should be explicitly defined
[03:08:52] <jmkasunich> step-type is an integer
[03:09:03] <SWPadnos> $(ctrl_type) | $(step_type)<<2
[03:09:29] <SWPadnos> if step_type needed all 32 bits, that should be an error, since the top two are getting lost
[03:09:29] <jmkasunich> since the legal values are 0-2, no other bits will ever be set
[03:09:39] <SWPadnos> right, but the tool doesn't know that
[03:09:44] <jmkasunich> yes it does
[03:09:46] <jmkasunich> line 38
[03:09:57] <jmkasunich> name : legal values : question
[03:10:04] <jmkasunich> oops, ignore the CHANGEABLE
[03:10:08] <SWPadnos> ok, so you want the tool to determine the range of legal values
[03:10:11] <SWPadnos> np
[03:10:35] <SWPadnos> so it only needs to insure that no significant bits are lost or overwritten
[03:10:37] <jmkasunich> the tool reads the range of legal values, and checks the user supplied against them
[03:10:58] <jmkasunich> the tool doesn't know anything about significant bits
[03:11:03] <SWPadnos> I'm not thinking of the input - I'm thinking about the output, which in this case is bitfields
[03:11:16] <jmkasunich> the module author does, when he writes the RAM_TEMPLATE
[03:11:32] <jmkasunich> man, I borked that all up
[03:11:38] <SWPadnos> heh - I guess I'm always thinking about error checking - even if I'm trying to check people who should know what they're doing
[03:11:53] <jmkasunich> in the ram template, step_up_phA, and dir_down_phB should be inside $()
[03:12:00] <jmkasunich> since I want to substitute for them
[03:12:23] <SWPadnos> and there shouldn't be any commas after $(ctrl_type)
[03:12:34] <SWPadnos> since there are only 4 REGS defined
[03:12:53] <jmkasunich> you're mixing things up
[03:12:59] <SWPadnos> ok :)
[03:13:13] <jmkasunich> the 4 regs are the registers that the driver accesses at runtime (realtime)
[03:13:19] <SWPadnos> ah, ok
[03:13:23] <jmkasunich> they have nothing to do with the 1K data
[03:13:50] <SWPadnos> ah. the RAM_TEMPLATE should have the number of bytes/words needed for the instance type, I think
[03:14:01] <jmkasunich> there are actually 7 bytes for this template
[03:14:26] <SWPadnos> I see 6, except that I know BASEADDR needs to be 2 bytes
[03:14:31] <jmkasunich> idcode is 1, instance is 1 (I doubt we'll need more than 256 instances of anything), baseaddr is 2
[03:14:44] <jmkasunich> the tool doesn't know - thats another oversight
[03:15:10] <jmkasunich> there also probably needs to be some syntax for "this is an expression"
[03:15:22] <SWPadnos> it also doesn't know that it needs to trim the byte containing ctrl_type and step_type
[03:15:24] <jmkasunich> in the ram, the result of the template isn't a string, its a stream of bytes
[03:15:39] <SWPadnos> sure
[03:15:48] <SWPadnos> a string would be awfully inefficient
[03:15:54] <jmkasunich> maybe it should assume that each item (between commas, or maybe we can do one per line) is an expression for a byte
[03:16:16] <SWPadnos> yep, and provide HIGH() and LOW() operators
[03:16:22] <jmkasunich> so $(BASEADDR>>8), $(BASEADDR)
[03:16:49] <SWPadnos> sure
[03:16:51] <jmkasunich> or operators...
[03:17:05] <SWPadnos> >> and << are operators, so they're already in there
[03:17:15] <jmkasunich> the expression parser/evaluator will be a pain to write
[03:17:19] <SWPadnos> not really
[03:17:35] <SWPadnos> that's a pretty well-known problem these days
[03:17:43] <jmkasunich> you volunteering?
[03:17:46] <jmkasunich> ;-)
[03:18:01] <SWPadnos> well, I actually wrote a complete infix -> postfix evaluator for a function generator when I was in college (in Pascal) :)
[03:18:16] <jmkasunich> I bet you didn't bang it out in one or two evenings
[03:18:28] <SWPadnos> I'll bet Pete can do it in an afternoon with antlr and friends ;)
[03:18:35] <SWPadnos> no, it took a couple of days
[03:18:59] <SWPadnos> but it had trig and other functions, variables, and operators
[03:19:02] <jmkasunich> anyway, the expression syntax isn't the important part - other than "there is a syntax, and it makes one byte per line"
[03:19:07] <SWPadnos> plus parens and stuff
[03:19:10] <SWPadnos> right
[03:19:25] <jmkasunich> lemme update the pastebin
[03:19:31] <SWPadnos> I'd actually make it like that, rather than one byte per comma
[03:19:55] <SWPadnos> the RAM stuff won't be all that long, and having things on one line may allow for # comments
[03:20:02] <SWPadnos> err - one byte per line, that is
[03:20:23] <jmkasunich> right
[03:20:41] <jmkasunich> I think I'm also gonna put the section titles in [], like inifile sections
[03:20:51] <SWPadnos> I'd also say that ID_CODE is a required variable (the tool should throw some error if it's not found)
[03:21:14] <SWPadnos> and I think it may make sense to automatically stick the ID_CODE and INSTANCE in the RAM stream
[03:21:40] <SWPadnos> but I can see wanting the tool to be simple, and therefore requiring the author to specify those
[03:21:58] <jmkasunich> only level 4 users have to worry about forgetting the ID_CODE and INSTANCE, I'd rather keep the tool simpler
[03:22:16] <jmkasunich> besides, some modules might only ever have one instance
[03:22:32] <SWPadnos> actually, ID_CODE, INSTANCE, and BASE_ADDR are all required for any module I can think of
[03:22:36] <SWPadnos> sure
[03:23:15] <jmkasunich> I suppose we could make those standard, and have the core driver process them before the big switch statement... thats a little less code in each module
[03:23:22] <jmkasunich> a detail though
[03:23:23] <SWPadnos> yep
[03:23:27] <SWPadnos> to both
[03:25:08] <SWPadnos> in those examples, is the ctrl_type meant to change the stepgen functionality, or just the default mode (ie, can the stepgen do either, selectable later?)
[03:25:39] <jmkasunich> it changes the HAL pins that are exported
[03:25:45] <jmkasunich> so its an insmod param, not a hal param
[03:26:15] <jmkasunich> infact, thats a mapping that I didn't think about, but is really what this whole thing is doing
[03:26:19] <SWPadnos> ok, so it doesn't change the functionality, only the default?
[03:26:27] <jmkasunich> PRE_FPGA_VARS are "hardcoded" stuff
[03:26:35] <SWPadnos> sure - the pin can't be moved
[03:26:41] <jmkasunich> POST_FPGA_VARS are things that would be insmod params for a simpler driver
[03:26:57] <jmkasunich> they can't be insmod params here, we simply have to much info to pass
[03:27:17] <SWPadnos> ah - those are set by the "user config" tool
[03:27:21] <jmkasunich> right
[03:27:31] <SWPadnos> hence the values and text strings
[03:29:00] <jmkasunich> updated:
http://pastebin.ca/499569
[03:29:11] <jmkasunich> the more I think about this the more I think its two tools
[03:29:21] <jmkasunich> both of which read the module spec for hints
[03:29:42] <SWPadnos> ok - I'm pretty sure that's the right way to go
[03:29:46] <jmkasunich> tool 1 is used by type 3 people to make new top level VHDL
[03:29:51] <SWPadnos> we can still have one library that reads the data
[03:30:10] <jmkasunich> tool 2 is used by type 2 folks to "tweak" it within the limitations of the post fpga vars
[03:30:24] <jmkasunich> type 1 folks are the only ones being left out (sort of)
[03:30:51] <jmkasunich> take stepgen for example
[03:31:18] <jmkasunich> step_type _could_ be a HAL param, since it doesn't (neccessarily) modify the list of HAL pins to be exported
[03:31:42] <jmkasunich> ctrl_type must be known at insmod time, so it must be set by the tool
[03:31:51] <jmkasunich> those scared to use the tool lose out
[03:32:32] <jmkasunich> and maybe thats ok
[03:32:39] <SWPadnos> future discussion topic: polymorphic HAL modules
[03:33:17] <jmkasunich> btw, not that the pin driver ram template doesn't include instance or base address
[03:33:23] <jmkasunich> there will always be one of those per pin
[03:33:43] <SWPadnos> hmm
[03:34:33] <SWPadnos> how does the driver talk to the pin drivers then?
[03:34:39] <jmkasunich> while we're talking about the pin driver
[03:34:50] <jmkasunich> remember I said GPIO and pin driver would be separate?
[03:34:54] <SWPadnos> or is it assumed that those are all at the start (or end) of the PCI address space?
[03:34:57] <SWPadnos> yes
[03:34:59] <jmkasunich> the pastebin was made two days ago before that split
[03:35:12] <SWPadnos> ok
[03:35:27] <jmkasunich> hal_mode invert, hal_output, and hal_input really belong in the GPIO part
[03:35:51] <jmkasunich> hal_mode was an attempt to help type 1 folks
[03:36:12] <jmkasunich> but you really want mode to be fixed at insmod time
[03:36:27] <jmkasunich> if the mode is 0 (input only) then you know that you only export an input HAL pin
[03:36:30] <jmkasunich> etc
[03:36:38] <SWPadnos> hmm. if a pin driver is connected only to a special function module and not to a GPIO, then those things need to be (a) initialized at insomd time or (b) connected to the specialized module
[03:37:01] <jmkasunich> the ones labeled hal_, or the others?
[03:37:07] <SWPadnos> or (c) part of the FPGA config, as constants
[03:37:26] <SWPadnos> basically all the connections in the diagram
[03:38:00] <SWPadnos> they either need to be hardwired or set at insmod time if and only if a pin isn't connected to a GPIO module
[03:38:02] <jmkasunich> mode and invert are connected to 72 bit writable registers (3x24 bit actually ;-)
[03:38:16] <jmkasunich> and are set by the driver, using the packed bits in the 1K data
[03:38:51] <SWPadnos> ok - that sounds like it'll either be "interesting" to stick into this module spec file, or it'll be left out entirely and just assumed
[03:39:09] <jmkasunich> IF I was gonna support the type 1 users, then if the "hal_mode" bit in the 1K is true, there will be a HAL param called "mode", initialized with the value from the 1K, but changable by the users
[03:39:34] <jmkasunich> pin drivers are gonna have some "assumed" things I think
[03:40:09] <SWPadnos> you may need the PRE_FPGA vars for all those hal_* bits, to set the defaults
[03:40:21] <jmkasunich> why pre-fpga?
[03:40:46] <jmkasunich> the raw fpga config will have all pins disabled
[03:40:49] <SWPadnos> well, the export bits don't hold the default values
[03:40:55] <SWPadnos> ok
[03:41:02] <jmkasunich> when the driver is loaded, it will read the 1K and write the regs based on that
[03:41:58] <SWPadnos> ah - duh. I was missing the [parts that don't have hal_ in front. nevermind
[03:43:23] <jmkasunich> jumping around a bit...
[03:43:30] <jmkasunich> I have some thoughts on the user config tool
[03:43:37] <SWPadnos> ok
[03:44:52] <jmkasunich> its main input, and its output, should be the same file format... said file should contain the FPGA bitstream, the POST_FPGA questions and such, the current values for each instance of those variables, and the resulting 1K block
[03:45:28] <jmkasunich> so you'd open a .fgpa file, it would ask you a bunch of questions, then either save (save file with new answers and corresponding 1K block) or save as to use a different name
[03:46:13] <jmkasunich> since the bitfile format supports many independent data blocks, we could put each class of stuff in a different block
[03:46:47] <jmkasunich> xilinx uses "a" thru "e", and I currently use "w" (for "write this to the 1K ram after loading the bitstream")
[03:47:56] <SWPadnos> actually, if you support defaults for the changeable settings, the 1k ram block writer can just be a filter that just sets everything to default without asking
[03:48:05] <SWPadnos> the tool that asks the user changes the default values
[03:48:46] <jmkasunich> I dunno if the "defaults" would come from the module spec, or from the level 3 user
[03:49:13] <jmkasunich> the level 3 user has to provide values for all the pre-fpga variables
[03:49:19] <SWPadnos> the level 4 user can sepcify defaults (and I guess use 0 or the first encountered value if no default is specified)
[03:49:30] <jmkasunich> I'm tempted to have him provide values for pre and post, and use the post for the defaults
[03:49:31] <SWPadnos> this is for the post-FPGA stuff though
[03:50:07] <jmkasunich> you're right - "use the first answer in the list" lets the level 4 user spec the default
[03:50:33] <jmkasunich> the level 3 user can write "<some-post-fpga-var>=value", or not - if not, it uses the level 4 default
[03:50:44] <SWPadnos> or add a "DEFAULT=" keyword
[03:50:54] <jmkasunich> I suppose
[03:51:01] <jmkasunich> thats a detail for the module spec
[03:51:13] <SWPadnos> actually, set everything to 0, then level 4 defaults, then level 3 defaults
[03:51:25] <SWPadnos> true
[03:51:50] <jmkasunich> I'm thinking that the level 3 tool isn't interactive like the level 2 one
[03:52:00] <jmkasunich> the level 3 guy writes a "FPGA spec"
[03:52:17] <jmkasunich> that says how many of each thing he wants, with values for the various pre and post fpga vars
[03:52:29] <jmkasunich> (even the pre- ones could have defaults I guess)
[03:52:38] <jmkasunich> some of them anyway
[03:52:57] <SWPadnos> I think the level 3 tool should be interactive sme day, so the spec format should be designed with that in mind
[03:53:12] <jmkasunich> the fpga spec then becomes input the the FPGA make process (makefile) and the output is a .fpga file
[03:53:24] <jmkasunich> then the level 2 tool can be used to tweak the .fpga file
[03:54:01] <jmkasunich> by having the FPGA spec be a file, it lets make do its thing - that file is the source
[03:54:08] <SWPadnos> I don't know that I'd want to force a level 3 user to edit a spec file, but it may be reasonable
[03:54:20] <jmkasunich> (we could of course have an interactive tool that generates the file)
[03:54:27] <SWPadnos> yes - that would be good some day
[03:55:52] <jmkasunich> hmm... my train of thought seems to have run out of steam
[03:56:27] <SWPadnos> heh
[03:56:35] <jmkasunich> I need a workflow drawing (or something, drawings take too long to make)
[03:56:36] <SWPadnos> I think I can, I think I can, I ...
[03:56:46] <jmkasunich> I think I can think
[03:57:11] <SWPadnos> I'm thinking I'd like to make it two days in a row that I get to bed before 3 AM :)
[03:57:26] <jmkasunich> yep
[03:57:30] <SWPadnos> I like what you've got so far
[03:57:43] <jmkasunich> lets see if we can define the workflow and the files
[03:57:50] <jmkasunich> formats can follow on another day
[03:57:52] <SWPadnos> I would probably make some changes to the specific syntax, but that's a minor thing at this point
[03:57:56] <SWPadnos> yep
[03:58:30] <SWPadnos> level 4 user must write spec files for his FPGA creations
[03:58:45] <jmkasunich> yeah
[03:59:02] <jmkasunich> I was trying to "draw" it as (tool) -> file -> (tool)
[03:59:08] <jmkasunich> but that doesn't work
[03:59:09] <SWPadnos> one thing: it looks like we're expecting the tool to be able to read multiple specs, then output some aggregation of specs to one file, based on what's in the FPGA
[03:59:12] <jmkasunich> its not a single path
[03:59:26] <jmkasunich> multiple module specs, yet
[03:59:27] <jmkasunich> yes
[03:59:33] <SWPadnos> so there is no tool for level 4 - they're the source of spec files
[03:59:39] <jmkasunich> right
[03:59:52] <jmkasunich> level 4 writes module specs
[03:59:59] <jmkasunich> level 3 writes fpga specs
[04:00:14] <SWPadnos> level 3 tool input is multiple spec files and some user decisions about quantities and arrangements of things, plus some default overrides
[04:00:15] <jmkasunich> the toolchain turns an fpga spec into a .fpga file
[04:00:30] <jmkasunich> yes
[04:00:36] <jmkasunich> level 3 tool is the first step of the chain
[04:00:51] <SWPadnos> level 3 tool output is whatever make needs to make the bitfile, plus whatever files are neede dfor the level 2 user
[04:00:51] <jmkasunich> the second step has even more input - all the individual vhdl files, etc
[04:01:01] <jmkasunich> right
[04:01:05] <SWPadnos> which may just be all the spec files used, concatenated together, with changed defaults
[04:01:17] <jmkasunich> except that I'm hoping everything the level 2 user needs can be packed into the .fpga file
[04:01:23] <SWPadnos> let's hope so
[04:01:43] <SWPadnos> ah right - we can have an "s" section, for "specs" in the .fpga file
[04:01:44] <jmkasunich> then the level 2 tool accepts as input a .fpga file, and produces another .fpga file
[04:02:14] <SWPadnos> right, with a modified "w" section
[04:02:22] <jmkasunich> yep
[04:02:35] <SWPadnos> and the level 1 user never sees any of this
[04:02:40] <jmkasunich> the fpga file won't need to have entire module specs in it
[04:02:41] <SWPadnos> is that it? :)
[04:02:48] <SWPadnos> no, just the POST_FPGA sections
[04:02:53] <jmkasunich> only the post-fpga variable info and the ram template
[04:03:23] <jmkasunich> I think so
[04:03:38] <jmkasunich> I wonder whats the best way to document the flow
[04:03:50] <SWPadnos> so the level 3 tool is the most complex, and the most important for customizations
[04:04:11] <jmkasunich> dunno if 3 or 2 is more complex
[04:04:17] <jmkasunich> 2 needs to be "prettier"
[04:04:33] <SWPadnos> 3 takes a lot of info and reduces it, 2 only makes changes to a static dataset
[04:04:34] <jmkasunich> 3 will be invoked by make, files in, files out, no real user interface
[04:04:48] <SWPadnos> 3 has the potential for a really big hairy UI
[04:04:59] <jmkasunich> not at all
[04:05:04] <SWPadnos> consider a directory with 50 spec files, and somebody trying to arrange them in an FPGA
[04:05:35] <SWPadnos> with multiples of a few, plus some specific groupings (like PWM/encoder/a few GPIO as a group, *6)
[04:05:38] <jmkasunich> the proposed future "interactive fpga spec writer" will have to deal with that
[04:05:43] <SWPadnos> right ;)
[04:05:54] <SWPadnos> as I said - potential for hairyness
[04:06:05] <jmkasunich> ok, terminology
[04:06:20] <SWPadnos> the inputs are undefined and expandable, but for level 2 they're not expandable - just changeable
[04:06:26] <jmkasunich> when I say "level 3 tool" I'm thinking of the one that takes an fpga spec as input
[04:06:31] <SWPadnos> ah
[04:06:46] <jmkasunich> we need names
[04:06:46] <SWPadnos> I'm thinking of generating the FPGA spec, since that's the level 3 user's job
[04:07:20] <jmkasunich> fpga-spec-editor? fpga-spec-wizard? for the interactive one
[04:07:32] <SWPadnos> well, let's name the files first :)
[04:07:48] <SWPadnos> level 4 user generates a module spec per new module type
[04:07:48] <jmkasunich> fpga-preprocessor? for the one that takes an fpga spec and makes top level VHDL + other stuff
[04:07:53] <SWPadnos> sure
[04:08:59] <jmkasunich> * jmkasunich opens up a new pastebin ;-)
[04:09:05] <jmkasunich> just like an editor window almost
[04:09:08] <SWPadnos> been there, doing that ;)
[04:09:29] <jmkasunich> ok, you can drive this time, don't want to duplicate
[04:09:47] <jmkasunich> level 4 uses text editor to make module-specs
[04:09:50] <SWPadnos> ok - writing it now, be a sec for draft 1
[04:10:05] <jmkasunich> level 3 uses text editor now, wizard later, to make fpga-spec
[04:10:33] <jmkasunich> level 3 user invokes make, which runs fpga-spec-preprocessor and then the fpga toolchain, and then a post-processor, to make a .fpga file
[04:10:50] <jmkasunich> the postprocessor merges the extra sections into the bitfile
[04:11:05] <jmkasunich> (I have a crude postprocessor now, to merge the 1K data)
[04:11:33] <jmkasunich> level 2 uses fpga editor to modify post-fpga variables, and generate a revised .fpga file
[04:11:52] <jmkasunich> level 1 users loads .fpga file into the hardware and uses whatever is in HAL
[04:13:15] <jmkasunich> development priority: first, the pre- and post-processors - without those, can't do anything
[04:13:34] <jmkasunich> next, the fpga editor - without that, only level 3 users can change things
[04:13:50] <jmkasunich> last, the fpga-spec-wizard - makes life easier for level 3 users
[04:16:21] <SWPadnos> ok, draft 1 is here:
http://pastebin.ca/499607
[04:18:46] <SWPadnos> I guess a little more info would be good for the output of level 3
[04:21:13] <jmkasunich> the preprocessor doesn't take in vhdl
[04:21:23] <jmkasunich> it takes in the configuration file and outputs vhdl
[04:22:13] <SWPadnos> I was thinking that it would do substitutions on existing files, but that may be in error
[04:22:32] <jmkasunich> there will be a top level VHDL file template
[04:22:35] <SWPadnos> I'm not sure if there needs to be some preamble and postamble, dependend on the specific card used
[04:22:41] <jmkasunich> but I don't think of that as true vhdl
[04:22:58] <SWPadnos> ok - that can be reworded as inputs "VHDL templates"
[04:23:00] <SWPadnos> ok
[04:23:12] <jmkasunich> I'll do this editing pass....
[04:24:00] <jmkasunich> hmm, I think for at least the level 3 user we need to split the process into stages
[04:24:10] <SWPadnos> heh - ok
[04:33:59] <jmkasunich> http://pastebin.ca/499615
[04:39:35] <SWPadnos> ok - looks good to me for workflow, I might make a couple of changes to the extra fpga file sections (and htespecs)
[04:39:43] <SWPadnos> but those are details for another day, I think
[04:39:48] <jmkasunich> the section names were pulled out of my rear
[04:40:03] <SWPadnos> no wonder :)
[04:40:15] <jmkasunich> splitting the options themselves (one set per module) and their current values (one set per instance) seemed to make sense to me
[04:40:34] <SWPadnos> sure - I think 2 or 3 secdions can do the job though
[04:40:47] <SWPadnos> the RAM section is needed, and it has the current settings in it (by definition)
[04:40:59] <SWPadnos> those would be the default settings at the end of stage 3
[04:41:08] <jmkasunich> also, I noticed that both the post-processer and the level 2 editor will be making 'w' sections using 't' and 'v' sections
[04:41:23] <SWPadnos> yes
[04:41:29] <jmkasunich> thats either duplicated code (can be a library), or it indicates a redundancy in the workflow
[04:41:43] <SWPadnos> the fpga file should be usable after stage 3, without ever going through stage 2
[04:41:48] <jmkasunich> maybe the bitfile loader could generate the 'w' on the fly?
[04:42:24] <jmkasunich> the RAM section has the current settings in it, but not in a form that could be extracted easily
[04:42:34] <SWPadnos> it could, but I think I'd rather have the level 2 GUI save the user choices in the 'w' section, and leave the defaults in the 'o' section
[04:42:43] <SWPadnos> I'd combine 't' and 'o'
[04:43:00] <SWPadnos> and also 'v' and 'w'
[04:43:02] <jmkasunich> the interactive editor is gonna want to know the current/default value of "foo", not have to extract it from bits 2-5 of byte 7
[04:43:22] <SWPadnos> well, it has to know how to put it into bits 2-5 of byte 7
[04:43:28] <SWPadnos> going the other way shouldn't be too hard
[04:43:36] <jmkasunich> t is the map
[04:43:48] <jmkasunich> inverting the map seems like alot of work for nothing
[04:44:12] <SWPadnos> it gives you the actual current settings, which could be valuable in debugging situations
[04:44:18] <jmkasunich> combineing t and o make some sense - both are per module, not per instance
[04:44:19] <SWPadnos> think of that as a "config viewer" function
[04:44:36] <jmkasunich> the viewer should use 'v'
[04:44:48] <jmkasunich> the format of 'w' is a 1K binary lump
[04:45:11] <SWPadnos> it should be a pretty well known lump though
[04:45:17] <jmkasunich> the format of 'v' might be lines like "stepgen.3.ctrl_type = 1"
[04:45:19] <SWPadnos> all the specs are in the other sections
[04:45:43] <jmkasunich> I really don't want to go from 'w' to anything
[04:45:57] <SWPadnos> it can have both, but I think I'd still like to be able to verify that the RAM is actually set for whatever is in the 'v' section
[04:45:59] <jmkasunich> the packing from variables to binary is completely arbitrary, determined by the module author
[04:46:15] <jmkasunich> there is no reason he should even have to think about ensuring that it is reversible
[04:46:36] <SWPadnos> I'm not sure I can think of a case where it wouldn't be reversible
[04:46:43] <jmkasunich> the 'v' to 'w' transform is straighforward, and defined by the ram template
[04:46:51] <SWPadnos> it's only bitfields and bytes (possibly combined into words)
[04:47:09] <jmkasunich> $(foo)<<$(bar)
[04:47:23] <jmkasunich> given the result of that, please find foo and bar ;-)
[04:47:32] <SWPadnos> heh
[04:47:46] <SWPadnos> I'm not sure I can think of a useful case that isn't reversible ;)
[04:48:03] <SWPadnos> usefiul in this context
[04:48:11] <jmkasunich> I'm not sure why we should even try to reverse it though
[04:48:31] <SWPadnos> I can see using that construct, but only for things that are implicit, like $INSTANCE
[04:48:46] <SWPadnos> verification
[04:49:09] <jmkasunich> verifying what? that a particular 'w' matches a particular 'v'?
[04:49:29] <SWPadnos> consider this - that the specific 'w' in the file matches what you or someone else thinghs it should be
[04:49:32] <jmkasunich> do the forward transform, and compare the resulting 'w' (in memory) with the 'w' in the file
[04:49:33] <SWPadnos> thinks
[04:50:00] <SWPadnos> that's about as useful as "HAL: module load error -1 (Operation not permitted"
[04:50:03] <SWPadnos> )
[04:50:11] <jmkasunich> or don't even generate the 'w' until you need it, at fpga load time
[04:50:18] <SWPadnos> that wold also work
[04:50:37] <SWPadnos> multiple locations for holding the same data are generally bad things
[04:50:52] <jmkasunich> I just think having a bunch of individual "name = value" lines stored in the file is all-around better/easier than having packed binary in the file
[04:51:03] <SWPadnos> but you can eliminate the 'v' section if the tool can "read" the 'w' section
[04:51:11] <SWPadnos> sure
[04:51:13] <jmkasunich> given the name/value pairs and the template, you can make the w easily
[04:51:33] <SWPadnos> true, though it's "safer" to generate the binary once and keep loading it
[04:51:42] <jmkasunich> why?
[04:51:59] <SWPadnos> because it's not dependent on as many tools, which could change and introduce incompatibilities or bugs
[04:53:00] <jmkasunich> given this:
[04:53:01] <jmkasunich> [RAM_TEMPLATE]
[04:53:01] <jmkasunich> $(ID_CODE)
[04:53:01] <jmkasunich> $(INSTANCE)
[04:53:01] <jmkasunich> $(BASEADDR>>8)
[04:53:01] <jmkasunich> $(BASEADDR)
[04:53:03] <jmkasunich> $(ctrl_type) | $(step_type)<<2
[04:53:05] <jmkasunich> $(step_up_phA)
[04:53:07] <jmkasunich> $(dir_down_phB)
[04:53:23] <jmkasunich> and name/value pairs, you darned well better be able to generate the correct result
[04:53:29] <SWPadnos> heh
[04:53:57] <jmkasunich> and the more I think about it, the more I want to do that as late in the process as possible
[04:54:35] <jmkasunich> although it would be good to generate the 'w' section during the make, just to make sure that the template isn't borked
[04:54:56] <jmkasunich> once the template (and name/value pairs) are stored in the bitfile, they're not gonna change
[04:56:22] <SWPadnos> either way is fine
[04:56:38] <jmkasunich> we're diving down into details again
[04:56:58] <SWPadnos> on a separate note, I'd still leave the default values (generated in type 3 or 4) in the 't' section
[04:57:14] <SWPadnos> so you have defaults and current settings available in the GUI
[04:57:14] <jmkasunich> t is the template
[04:57:40] <SWPadnos> ah - then the 'o' section should have the defaults
[04:57:57] <jmkasunich> right
[04:57:58] <jmkasunich> editing now
[04:58:07] <jmkasunich> 'o' section: configuration options (per module, with defaults)
[04:58:18] <SWPadnos> right
[04:59:17] <jmkasunich> output:
[04:59:18] <jmkasunich> a bitstream file with additional data:
[04:59:18] <jmkasunich> 'o' section: configuration options (per module, with defaults)
[04:59:18] <jmkasunich> 'v' section: current values for each option (per instance)
[04:59:18] <jmkasunich> 't' section: ram template for translating 'v' into 'w' (per module)
[04:59:18] <jmkasunich> 'w' section: config ram contents - 1K bytes, packed binary
[04:59:46] <jmkasunich> o and t are transcribed from the module specs
[05:00:04] <SWPadnos> yep, and they don't change in this stage
[05:00:09] <jmkasunich> v comes from the fpga spec (and is modified by level 2 users with the fpga editor)
[05:00:15] <SWPadnos> v and if it's there w would change
[05:00:21] <jmkasunich> w is created from v and t
[05:02:58] <jmkasunich> http://pastebin.ca/499631
[05:03:06] <jmkasunich> both options for 'w' are in there now
[05:04:25] <SWPadnos> I think the config loader shouldn't have to parse all the text bits - it should just get a 'w' section
[05:05:00] <SWPadnos> that would allow all the type 2+ stuff to be left out of a normal install
[05:05:25] <jmkasunich> yeah, the more I thought about it the less I liked that idea
[05:05:59] <jmkasunich> you could generate a bitfile with only the xilinx and the 'w' section
[05:06:06] <SWPadnos> yep
[05:06:10] <jmkasunich> but the editor would no longer be able to do anything with it
[05:06:29] <SWPadnos> right - isn't it an external program thatsticks the RAM stuff into one of the FPGA RAM blocks?
[05:06:39] <jmkasunich> the loader does it
[05:06:49] <SWPadnos> unless the operations were reversible ...
[05:06:51] <jmkasunich> if we stick with a 'w' section, the loader is already done
[05:07:25] <jmkasunich> oh, you mean actually stick it into the xilinx bitstream, so the RAM has the right content as soon as the fpga is configured?
[05:07:33] <SWPadnos> yes
[05:07:45] <SWPadnos> I thought that was what at least one ofthe programs you found did
[05:07:56] <jmkasunich> that requires much screwing around with xilinx tools to see where in the bitstream the ram content is
[05:08:07] <jmkasunich> I never got it to work right
[05:08:13] <SWPadnos> ok - nevermind then
[05:08:57] <jmkasunich> oh, I just remembered, its worse
[05:09:16] <SWPadnos> uh oh
[05:09:18] <jmkasunich> you can't just have the xilinx tool tell you where to stick it, and then stick it using your own tool
[05:09:39] <jmkasunich> the actual sticking has to be done by the xilinx tool, to preserve the bitstream CRC
[05:09:50] <jmkasunich> that means level 2 users would need the xilinx tools - not acceptable
[05:10:11] <SWPadnos> hmmm
[05:10:50] <SWPadnos> so there have to be two files, which we were trying to avoid
[05:10:57] <jmkasunich> no
[05:11:05] <SWPadnos> because the level 2 user can't modify the fpga file
[05:11:12] <jmkasunich> the w section is part of the bitstream
[05:11:20] <SWPadnos> oh wait- you're atalking about sticking the RAM contents into the bitfile portions
[05:11:24] <jmkasunich> sorry, inprecise speaking
[05:11:42] <jmkasunich> the 'e' chunk of the FPGA file has the xilinx bitstream, with CRC
[05:12:18] <jmkasunich> the 'w' chunk has the ram content, which is written to the FPGA by the loader after the bitstream is loaded
[05:12:35] <jmkasunich> we can't merge the ram data into the 'e' chunk
[05:12:40] <SWPadnos> ok, no problem
[05:12:57] <jmkasunich> the only time a separate file will exist is during make
[05:13:19] <jmkasunich> the pre-processor will generate a file containing the 'o', 'v', and 't' stuff
[05:13:34] <jmkasunich> the xilinx tools create a file containing 'a' thru 'e'
[05:13:39] <SWPadnos> well, we can go on all night about the specifics, but I'm thinking my nice down quilt is more appealing at the moment ;)
[05:13:51] <jmkasunich> the postprocessor merges them, at which point the 'ovt' file can be deleted
[05:13:56] <jmkasunich> yeah
[05:14:05] <jmkasunich> I'm quite pleased with what we have right now
[05:14:22] <jmkasunich> not looking forward to writing the tools, but at least we know what needs done
[05:14:23] <SWPadnos> but we can modify the 'o' 'v' 't' and 'w' parts as much as we like, without the xilinx tools, right?
[05:14:28] <jmkasunich> right
[05:14:37] <SWPadnos> ok, then we can wait for the specifics ;)
[05:14:40] <jmkasunich> I have a library for writing files in that format
[05:14:45] <SWPadnos> cool
[05:14:59] <SWPadnos> yep - I'm happy with the system we've outlined
[05:15:00] <jmkasunich> it reads the file and pulls out the chunks, or takes chunks and writes the file
[05:15:35] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/utils/bitfile.h?rev=1.1
[05:15:44] <SWPadnos> I may have some time tomorrow to fiddle with the spec language a bit
[05:17:32] <jmkasunich> I'll write the postprocessor
[05:18:01] <jmkasunich> (thats easy - take two bitfiles, one with a thru e chunks, and one with vot and maybe w chunks, and merge them
[05:18:52] <SWPadnos> that program should also pull out the correct sections from the spec files to put them in the fpga file
[05:19:07] <jmkasunich> no, the pre-processor will do that
[05:19:31] <SWPadnos> ah right - generates o t v files
[05:19:37] <jmkasunich> (pre-processor opens all the module specs anyways, so it can create a file with the v, o, and t chunks
[05:22:24] <jmkasunich> goodnight
[05:22:43] <SWPadnos> good night
[06:31:24] <alex_jon1> alex_jon1 is now known as alex_joni
[12:49:34] <jepler> if ((*(iocontrol_data->tool_change) != 0) && (*(iocontrol_data->tool_changed)==1)) {
[12:49:46] <jepler> hm do I read this wrong, or is it a bogus comparison of a hal_bit_t to 1?
[13:13:50] <alex_joni> tool_change is int iirc
[13:13:54] <alex_joni> changed is bit
[13:34:39] <skunkworks> give me some reasons why there isn't a real time usb driver for emc2 yet.
[13:34:53] <jepler> skunkworks: because nobody has contributed one
[13:35:06] <skunkworks> so - it would be possible?
[13:35:28] <skunkworks> or is usb not a really good realtime interface
[13:35:29] <jepler> beats me
[13:35:31] <skunkworks> ok
[13:35:32] <skunkworks> ;)
[13:36:22] <jepler> contrary to what you might think I'm no USB expert
[13:37:06] <skunkworks> jepler: thanks :)
[13:37:43] <jepler> I guess the other question is, what USB hardware do you want to control? As others have said recently, grex does not fit with the EMC model
[13:38:05] <jepler> step generation using a usb-to-parallel adapter sure won't work
[13:38:57] <jepler> so whoever develops/contributes the "USB driver" will really be developing three things: the USB device, the device-specific driver, and the generic RT USB driver (though I understand that there is already some kind of USB layer for RTAI)
[13:39:44] <skunkworks> Ok - that is more what I was looking for.
[13:40:42] <jepler> of course, emc 2.1 can use USB input devices such as keyboards and joysticks with halui to create operator panels, but I assume that's not what you're talking about
[13:41:09] <skunkworks> I could see someone making a step generator that was usb - like what jon has for the printer port. Or a encoder/dac card.
[13:43:30] <skunkworks> encoder counter/dac-pwm
[13:43:46] <skunkworks> that would fit well with emc - if the usb interface would be quick enough
[13:44:37] <skunkworks> jepler: did you end up hooking a different encoder to your board?
[13:44:58] <jepler> skunkworks: no, not yet
[13:45:40] <jepler> instead I worked this weekend on getting the on-board LED to be controlled by the PC -- it now reports to linux as a 'numlock' key
[13:47:36] <skunkworks> Any device that linux sees can be used as an input/output device now - correct? not just usb devices?
[13:48:17] <jepler> yes -- for instance, I've tested with a PS/2 mouse, a built-in laptop keyboard, a "joystick" with serial connection
[13:48:24] <jepler> umm I think that's about it
[13:48:41] <skunkworks> sweet.
[13:49:08] <skunkworks> * skunkworks is just trying to get his facts reletively strait.
[14:10:49] <SWPadnos> skunkworks, you asked about USB being "fast enough" - well, it probably is
[14:10:53] <SWPadnos> it's the latency that kills you
[14:11:08] <SWPadnos> and also the minor differences in clock speeds
[14:11:13] <SWPadnos> (that are inevitable)
[14:11:46] <SWPadnos> this is what happens with Jon Elson's parport devices, in the servo cycle (~1ms period):
[14:12:03] <SWPadnos> read everything from device (takes ~20-50 uS)
[14:12:13] <SWPadnos> process the data
[14:12:23] <SWPadnos> write everything (takes another 20-50 uS)
[14:12:40] <SWPadnos> then wait a relatively long time for the next 1ms tick to come around
[14:13:19] <SWPadnos> note that there's only the processing time and the write time between reading the then-current state of the machine and writing the new outputs
[14:15:14] <SWPadnos> with USB, there is no synchronization (there may be in the RTUSB driver jepler mentioned, but I'm not sure of it)
[14:16:08] <SWPadnos> so even though the USB packet rate is nominally 1000 packets/second, the tiny error in setting up the HAL thread period, plus the fact that the two clocks are not derived from the same source, will cause them to get out of sync
[14:16:21] <SWPadnos> (this is only one problem with USB and low latency)
[14:16:43] <SWPadnos> so every once in a while, there will be two data packets that arrive within the same servo cycle
[14:16:53] <SWPadnos> every once in a while there will be none
[14:18:31] <SWPadnos> also, the USB data stream is divided up into timeslices by the driver. I'm not sure exactly how the data gets from all the sources into the packet, but I suspect the driver needs to have the data before each packet cycle starts
[14:19:25] <jepler> SWPadnos sounds like one of these USB experts I mentioned earlier
[14:19:32] <SWPadnos> if this is the case, it means that we need to send command data (so the driver has it ready), then we receive new data and do calculations based on that
[14:19:34] <SWPadnos> heh
[14:19:57] <SWPadnos> but the new commands don't get sent to the device until the next cycle - there's a one-cycle delay in the ideal case
[14:20:52] <SWPadnos> in non-ideal cases, where you may need to ask the device for informaiton (a complex device may not report all data every cycle), you can add in another USB cycle latency
[14:21:15] <SWPadnos> clock skew is another non-ideal thing, as I mentioned
[14:22:13] <cradek> we can get 1-3? kHz servo cycle on a parport, 5-8? kHz on a pci card - I don't know why you'd want to use usb with all its problems
[14:22:32] <SWPadnos> the main reason is that "everyone else can" ,,,
[14:22:36] <SWPadnos> ...
[14:22:38] <cradek> I suspect people who think they want to use usb are just mistaken
[14:22:42] <jepler> if you end up with position reporting lagging 3 ms behind position commands, and your top speed is 50mm/second, that will look a lot like 0.15mm following error to emc.
[14:22:45] <cradek> yeah, or they have a silly reason like that
[14:23:05] <SWPadnos> well, there are reasons to use USB - it's cheap, ubiquitous, and has the bandwidth
[14:23:10] <cradek> good thing we aren't commercial - they have to do things for silly reasons
[14:23:11] <SWPadnos> I think USB2 could work, actually
[14:23:31] <SWPadnos> USB2 has the concept of a microframe, which are sent at 8 KHz
[14:23:45] <cradek> that does sound a lot more promising
[14:24:14] <SWPadnos> yes, though there's still some magic in the driver that I don't know about regarding whn the data is needed so it can be stuck in the data stream
[14:24:44] <SWPadnos> I was going to ask that USB guru who popped up on one of the lists, but never got around to it
[14:24:59] <jepler> I bet you could get really shitty open loop control (e.g., just shove the step waveform out to a USB device which plays it back) as long as you just cross your fingers about stuff like underruns...
[14:25:32] <SWPadnos> well, you can actually get very good open loop control - that's why so many people are so interested in the G-Rex
[14:25:33] <jepler> if I had to add a "controls motors via USB" bullet-item to the list of emc features, that's what I'd do.
[14:25:44] <SWPadnos> and it is closed loop on the G-Rex, if you want it to be
[14:26:30] <SWPadnos> as some people often point out (rightly or wrongly), it's all closed loop, it's just a matter of where the loop is closed
[14:26:44] <jepler> but that's not EMC as we know it, Jim
[14:26:47] <SWPadnos> if you use gecko drives, they close the loop
[14:26:50] <SWPadnos> I agree :)
[14:27:12] <SWPadnos> but there is the concept of running motion on one CPU and IO on another
[14:27:12] <cradek> I'll stick with emc as we know it
[14:27:29] <SWPadnos> there's no reason the motion CPU can't be at the end of a USB cable
[14:27:42] <SWPadnos> (it's no differnt than neing at the end of a network cable)
[14:27:45] <SWPadnos> gah
[14:29:02] <jepler> IMO it all goes back to what I said earlier: we don't have X because nobody's contributed it.
[14:29:10] <SWPadnos> I still haven't done it, but I still think about making an ARM board to go on the G-Rex instead of the Rabbit
[14:29:11] <SWPadnos> yep
[14:29:26] <SWPadnos> I think people have been pushed away from contributing it, actually
[14:29:32] <cradek> why has nobody contributed it is a better question
[14:29:51] <cradek> either it's a bad approach, or it's a bad match for emc, or some other reason?
[14:30:12] <jepler> nobody has the intersection of skills and need
[14:30:36] <SWPadnos> I think someone came along that did have the roght mix, but he got a less than stellar response
[14:30:45] <SWPadnos> I'm looking for the emails now
[14:31:03] <cradek> I remember that too
[14:31:19] <SWPadnos> Till Harbaum?
[14:31:26] <SWPadnos> 4/22/2007
[14:31:56] <cradek> I have a negative reaction to someone wanting to drip-feed a not-very-bright control using a PC that has a not-very-good idea of what's going on with the machinery
[14:32:02] <cradek> that's how I see these USB approaches
[14:32:34] <SWPadnos> I think it could work if you look at the USB link at the level of NML / CANON
[14:32:35] <cradek> I understand that's what people did years ago with the serial port behind their tape reader
[14:33:28] <cradek> SWPadnos: what you say is true, it could work
[14:33:36] <SWPadnos> in a sense, it points out a deficiency in the EMC communications scheme - we have some support for distributed IO and motion, but no RT communication between remotely connected devices
[14:33:52] <SWPadnos> (even "high latency RT)
[14:34:23] <jepler> I thought somebody did HAL over ethernet, and I wondered why it never got committed..
[14:34:41] <SWPadnos> was that Eric Johnson?
[14:34:48] <jepler> dunno
[14:34:52] <SWPadnos> or did he "only" do emcrsh?
[14:35:15] <jepler> he also did some telnet interface to halcmd, and that got committed
[14:35:19] <SWPadnos> right
[14:35:26] <SWPadnos> that's emcrsh, isn't it?
[14:35:44] <jepler> apparently it's called halrmt
[14:35:49] <SWPadnos> oh, thanks
[14:35:56] <SWPadnos> I didn't know htere were two of them ;)
[14:49:43] <skunkworks> Wow - thanks guys.
[18:03:05] <alex_joni> * alex_joni pings cradek
[18:16:33] <alex_joni> cradek: it seems run from line changed in TRUNK
[18:16:44] <alex_joni> it feels off by one..
[18:17:10] <alex_joni> in your simple example: G20 / G0x0y0z0 / G1x1y1z1 / M2
[18:17:25] <alex_joni> if I select the line with G1x1y1z1 and run from line, it simply ends..
[18:20:37] <cradek> yuck
[18:20:50] <alex_joni> If I am in x1y1z0, and select the G0 line it goes directly to x1y1z1
[18:21:03] <alex_joni> did you change something in axis regarding startline?
[18:21:15] <cradek> I'm not sure...
[18:21:29] <cradek> I was pretty sure that worked when I wrote that bug report
[18:22:10] <alex_joni> yeah
[18:22:15] <alex_joni> but you did it for 2.1.4
[18:22:22] <alex_joni> and in the 2.1 branch it does work
[18:22:29] <alex_joni> and I fixed the run from line bug
[18:22:34] <alex_joni> but now I wanted to patch TRUNK
[18:22:40] <alex_joni> and it behaves oddly
[18:23:06] <alex_joni> maybe you can test with a clean TRUNK? it might be only my code (although I doubt it)
[18:25:13] <alex_joni> I think numbering changed
[18:25:20] <alex_joni> program line numbers are now 1,2,3,4
[18:25:28] <alex_joni> and previously they were 0,1,2,3
[19:07:27] <alex_joni> * alex_joni cries
[19:08:02] <jepler> that's news to me
[19:08:37] <alex_joni> old point (25.400000, 25.400000, 25.400000, 0.000000, 0.000000, 0.000000), new point (25.400000, 25.400000, -0.000000, 3105036184601417870297958976925005110513772034233393222278104076052101905372753772661756817657292955900975461394262146412343160088229628782888574550082362278408909952041699811100530571263196889650525998387432937501785693707632115712.000000, 0.000000, 0.000000)
[19:08:56] <jepler> nice
[19:09:00] <alex_joni> not really..
[19:09:02] <jepler> looks like A never got set
[19:09:11] <alex_joni> and the worst part is that I never touched anything that does that
[19:09:23] <alex_joni> I set it in motion
[19:09:31] <alex_joni> but I bet interp overwrites it
[19:09:43] <alex_joni> can't find where :(( been looking for half an hour
[19:10:33] <alex_joni> although it shouldn't matter..
[20:37:31] <alex_joni> cradek: I think my code borked the run-from-line off by one
[20:37:41] <alex_joni> it updates the canon endpoint
[20:38:03] <alex_joni> and there's some funky stuff going on in canon which decides the move doesn't need to run (or something like that)
[22:56:20] <mschuhmacher> is there anyone here interested in minor bugs?
[23:00:35] <mschuhmacher> in TkEMC and Axis?
[23:01:53] <SWPadnos> no thank you. feel free to eliminate them :)
[23:03:12] <cradek> please tell us about them, but we might ask you to add them to the tracker if we can't fix them right away
[23:03:32] <mschuhmacher> ok
[23:05:37] <mschuhmacher> in the Axis-interface open file dialog, you can not open a file with [*], the filechooser adds an .ngc to the file you want to open and this results in a file not found error.
[23:05:53] <cradek> what do you mean with [*]?
[23:07:10] <mschuhmacher> files of arbitrary type e.g. plate.nc1
[23:08:11] <mschuhmacher> or files without extension
[23:08:18] <cradek> that works for me, say exactly what you're doing and I'll try it
[23:09:27] <cradek> and what version are you using?
[23:12:44] <mschuhmacher> I detected this error at home with my laptop and 2.1.?, but reproduced it with 2.1.5
[23:13:07] <mschuhmacher> file - open
[23:13:11] <mschuhmacher> all files
[23:13:16] <mschuhmacher> (*)
[23:13:59] <mschuhmacher> try to open emc2/configs/sim/README
[23:14:21] <mschuhmacher> it is really minor
[23:14:28] <cradek> oh so it's files without extension
[23:14:34] <cradek> I tried a .nc1 file, and .ngc~
[23:15:43] <cradek> ok I also get that if there is no extension
[23:16:51] <cradek> unfortunately that looks like it's a bug/misfeature of tk_getOpenFile
[23:17:04] <cradek> if you use -defaultextension, it always adds it if there isn't already one
[23:17:25] <cradek> we could take that out, but we'd lose the ability to type just "filename" to open filename.ngc
[23:18:13] <mschuhmacher> I think it is not very important to have the ability to open files without extension
[23:18:25] <mschuhmacher> but I tried to open one
[23:18:33] <mschuhmacher> and it faile
[23:18:37] <mschuhmacher> failed
[23:18:49] <mschuhmacher> I have to rename this file
[23:19:28] <cradek> let me see how it behaves without that option
[23:19:57] <SWPadnos> you can also put "" in the list of file patterns, which means "files with no extension"
[23:20:10] <SWPadnos> I'm not sure if that prevents -defaultextension from appending one though
[23:23:53] <mschuhmacher> in the mini - interface you can open any file and the default extension is *.nc
[23:24:31] <mschuhmacher> another one
[23:24:51] <mschuhmacher> in the Tk-EMC filechooser
[23:25:38] <mschuhmacher> the doubleclick didn´t work
[23:26:44] <cradek> I have also noticed that
[23:26:53] <cradek> for that one, you will probably have to file a bug report on sourceforge
[23:27:39] <SWPadnos> doubleclick is probably part of tcl, not tkemc
[23:28:23] <cradek> I think axis uses the same tk file chooser
[23:28:45] <SWPadnos> hmm. that could explain why it's also fairly ugly :)
[23:28:46] <cradek> (that makes me think something in tkemc is breaking it)
[23:28:47] <mschuhmacher> in the mini you can use a doubleclick
[23:28:48] <cradek> I have not looked
[23:29:21] <mschuhmacher> another one
[23:30:07] <petev> I found double click works sometimes in tkemc, seems like it needs a faster double click
[23:32:03] <mschuhmacher> in the TkEMC , when you change Units the toolpath changes, in Axis only the display of the units in the preview changes
[23:33:07] <cradek> mschuhmacher: what do you mean units of the toolpath?
[23:33:17] <cradek> what do you mean change units?
[23:33:36] <mschuhmacher> example:
[23:33:47] <mschuhmacher> open arcspiral.ngc
[23:34:31] <mschuhmacher> run it
[23:34:47] <mschuhmacher> toggle Units mm inches cm
[23:35:02] <mschuhmacher> turn on the Backplot
[23:35:03] <cradek> ok you mean change units on the gui menu
[23:35:09] <mschuhmacher> yes
[23:36:08] <cradek> tuple(s)
[23:36:10] <cradek> oops
[23:36:16] <mschuhmacher> notice there is m20 on the start of the program
[23:36:22] <cradek> g20 yes
[23:36:27] <mschuhmacher> yes g20
[23:36:33] <mschuhmacher> oops
[23:38:10] <cradek> ?
[23:39:30] <mschuhmacher> cradek: you changed the Units while runnig the program?
[23:41:16] <cradek> sorry, I'm not doing it, I'm waiting for you to explain the bug (what happened vs what you expected)
[23:41:28] <cradek> I'm still working on the first bug while you explain
[23:46:40] <cradek> fix for first bug (opening file with no extension in axis) checked in
[23:47:15] <cradek> I don't think I'll put it in 2.1 though, since it's a minor problem and it should be tested more
[23:49:37] <cradek> are you saying in tkemc the backplot changes size when you change units in the gui menu?
[23:50:25] <mschuhmacher> yes
[23:50:43] <cradek> ok are you saying that's the bug, or it's a bug that axis doesn't do that, or what?
[23:51:19] <cradek> I think it shouldn't change the size, only the numbers are shown - but I don't know yet if that's what you think
[23:51:29] <mschuhmacher> maybe the 2 guis shold behave the same way
[23:51:30] <cradek> err, the numbers THAT are shown
[23:51:48] <cradek> no, that's not an important goal. They should behave *right* instead
[23:52:07] <mschuhmacher> I thought also about the numbers
[23:52:19] <cradek> what precisely do you feel is the bug? I still don't understand
[23:52:21] <mschuhmacher> but I think the numbers are ok
[23:52:56] <cradek> you have not even said which gui you think has a bug, only that they are different
[23:53:40] <cradek> I'm not trying to be a jerk, but units issues are very complex and we need to be precise when we talk about them
[23:54:00] <mschuhmacher> yes it is very complicated
[23:54:24] <cradek> let me say first I don't know how tkemc handles this
[23:54:35] <cradek> but in AXIS there are three units settings
[23:54:44] <cradek> your INI file (defines the leadscrew pitches etc)
[23:54:50] <cradek> your gcode (g20 vs g21)
[23:55:05] <cradek> the gui units chosen in the menu, to decide how the numbers are shown
[23:55:11] <cradek> these are all completely separate
[23:55:38] <cradek> you can run an inch machine with a mm (g21) program, and have mm calipers in your hand to measure it - so you want the gui to show you mm
[23:55:52] <cradek> or ANY other combination of the three
[23:57:00] <cradek> you can see there are 8 combinations, it's very complicated
[23:57:33] <mschuhmacher> I considered it an I think it´s not worth the time to change it
[23:57:36] <cradek> tkemc may or may not allow you to use all 8 of these combinations
[23:58:17] <cradek> I can't say, because I don't yet understand the bug you are reporting
[23:58:43] <cradek> which gui is the bug in?
[23:58:58] <mschuhmacher> TkEMC
[23:59:11] <cradek> ok
[23:59:50] <cradek> if you think it's worth the effort to spell out precisely, please submit a bug report on the sourceforge tracker, I can help if you don't know how
