[8054] jmkasunich: well, thats a involved question .. I'd say in reallity it will probably end up around the 40Khz mark [8055] but it needs to be smoooooooth [8058] I have some thoughts on that [8059] say your period is 12.5uS -> 80KHz [8060] does it involve scheduling pulse events using the RT system to scedule 'only when I want them' events rather than discrete, fixed slices as it is now [8061] no, that is ugly [8062] it has to do with the difference between types of jitter [8065] and there is also a time penalty in reloading the timer... [8066] nods [8067] say you have a 12.5uS period, so your interrupt freq is 80KHz [8068] so you can do 40KHz (1 on, 1 off), and 26.667KHz (1 on, 2 off) [8069] but you want to make 30KHz [8072] if you run at 40K for 1mS, then change to 26K for a couple mS, then back to 40K, that is bad [8073] nods [8074] but what if you run at 40K for a single step, then change to 26K for a couple steps, then back to 40K for a step [8075] with uStepping drives that would most likely be OK [8076] that's what the hal stepgen does [8079] also what the G2003 does, but it has a higher max freq, so the steps are very small [8080] ustep drives drop into a squarwave/fullstep mode above a few khz anyway, so in reallity they might even translate as zero jitter in the drive output [8081] right [8082] on my to-do list is a test - run the hal stepgen output into a drive and motor, see how fast it will go before it gets rough, then run the output of a Wavetek (signal generator) into the same drive/motor combination and compare [8083] jitter analysis is non-trivial to be accurate with, but you can do a pretty good estimate with a scope [8086] yes, we can measure jitter with a scope (done that), but what we don't know (quantatively) is the effect of jitter on motors [8087] true [8090] almost quorate :) [8094] if you jump back and forth from one freq to another fast enough, the motor current _can't_ follow the jitter, it follows the average frequency...  but we don't know how fast is "fast enough" [8095] 10 names logged on - all but four are lurkers... [8096] although if the drive has a 20KHz PWM frequency, nothing faster than 20KHz is gonna make it to the motor [8097] hi ray [8098] I've been meaning to reply to the flurry of mail about serial/pic interfaces [8101] I think hal has a place there [8105] Duh! OK, here but not really awake.... where is Matt... wake up Matt! [8109] Matt raised a couple of topics to discuss... [8112] had hoped he'd be here nice and early. [8185] unless someone knows otherwise, I think we need to assume that Matt won't show up for an hour or so... [8190] I talked with Matt last night.  He should drop in before to long.  I may have kept him up late. [8195] EMC Monday - Are we having another one ? [8196] you mean in '04? [8197] Yup [8198] I've done some planning for it.  I'd really like to see it happen. [8199] I was assuming that we would [8202] Good assumption. [8203] Will it stretch to a hacking week ? [8204] (me needs to book flights before the end of the month) [8205] Given the great stimulus it provided to move EMC ahead, it MUST happen again. [8206] If you folk want it to stretch, it can. [8209] dunno... I doubt I could make the whole week, but a few days [8210] Would we want to stay right in taylor? [8211] good grief... [8212] Detriot for a Whole week ! [8213] Two days, with a location where we can leave some computers and stuff set up would be great. [8216] paul_c: Think the wrinkly would complain! [8217] Ma is staying behind. [8218] "Tears flow" [8219] haven't told her yet. [8220] how much space would we need? how many folks would hack? [8223] I can haul one PC over... [8224] I've got quite a bit of hardware and PC's. [8225] same here [8226] (nothing small though - desktops and such) [8227] Same for me. [8230] but I have a pickup [8231] could probably do with one set up as a server [8232] I have a 16 port ethernet switch [8233] That would be good.   [8234] has CAT5 cables [8237] ditto [8238] 50 metres [8239] RH knows nothing! [8240] I should have a mini-mill and a PC that goes to the NAMES show. My problem is that my travel partner would be taking my car back (with goodies) unless Matt has room again for me and my stuff. [8241] He will! [8244] You coming over from DC area ? [8245] Yes, I go up to Columbus, Ohio with a friend the day before. He returns at the end of NAMES and I try to hitch a ride back to the DC area. Matt is "close enough". [8246] paul_c: http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=2370093922 [8247] columbus? I'm in cleveland...  dunno if that helps any [8248] If things go according to plan, I'll be flying into/out from Dulles. [8251] How many days beyond "Monday" would we want to continue to work? [8252] 2-3 for me [8253] Paul - Do you rent a car and drive? A return to Dulles is even better than with Matt. I could share expenses on the car. [8254] yup - rent a car.. [8255] rent a minivan or SUV - loads of space for goodies [8258] get's expensive for the HGVs [8259] HGV? is that brit for SUV? [8260] kinda [8261] What would you think of holding the meetings at Smithy in Ann Arbor?  If they are willing. [8262] anyway, SUV/2 <= car/1 [8265] how far is ann arbor from NAMES? [8266] That would give us a Linux network with 1/2 T1 connection to the world. [8267] 20 min drive (60 at most) [8268] It's about a 20 minute drive on a good day. [8269] sounds reasonable [8272] back to the original question, how many of us and how much space [8273] so far we have paul, steve, ray, matt, me [8274] They have a running mill with servo amps and Gecko and a 3in1 with steppers and EMC. [8275] 5 people x say 4-5 feet each, we need 20+ feet of table space [8276] where we can leave stuff set up for a couple days [8279] Smithy is secure.  I worked there for three weeks last year. [8280] We might need to rent a few tables and chairs but that would be easy. [8281] sounds like a plan.  can you approach them about it? [8282] The closer alternative would be a mo/hotel with conference facilities and a www connection. [8283] probably pricey [8286] Yes I would think so.  And we would doubtless have to commit to a block of rooms. [8287] how many places provide a www conection ? [8288] Quite a few here now. [8289] if I had more space, I'd offer my basement - closer for most folks, but farther for Ray [8290] distance makes little difference to me... [8293] Three hour drive? [8294] yes [8295] Makes no difference to me but it might to a couple folk that I'm working on to attend. [8296] not big enough anyway - 20x20 minus junk, probably less than 10x15 available [8297] any place within 1000 miles of Detriot is OK by me. [8300] If you think Ann Arbor would be good, I'll ask.  There are inexpensive motels nearby and a great restaurant at Webers. [8301] ray_: those "couple folks" would attend the hacking week too> [8302] (wot, no Hooters ?) [8303] No Hooters -- the restaurant/bar anyway. [8304] not to worry - Found a Hooters this side of the pond. [8307] ray_: if so, we're up to 7 folks, 30+ feet of table [8308] The number of days that the hack would continue would be less of an issue if we find a place like Sm.   [8309] I think you should ask them - sounds like the best bet [8310] I was also thinking that we might find a school, teck, or such that might host us. [8311] the meeting rooms at Southgate an option? [8314] I was so P%$#@ off with the run around and interruptions last year that I had not consider a repeat for the money. [8315] fair enough [8316] sounds like Smithy is the best choice, if they'll have us [8317] If we could get the upstairs for three or four days that would be lockable. [8318] I'll ask Jim. [8321] As soon as I hear, I'll post a note to both user and devel lists. [8322] sounds good [8323] I don't think I could get one of my plasmas in as hand-baggage though [8324] yeah... [8325] all the machines at NAMES are very small [8328] airport security might have a fit... [8329] nods [8330] does this mean that robin might be making the trip? [8331] (w/o plasma) [8332] I feel an arm twist. [8335] it's only fair, last time I was the one getting twisted [8336] Fred P. said he'd be there for Monday. [8337] good [8338] I'll ask about three days. [8339] and Will? [8342] Great to hear that Fred is still in the loop! [8343] Don't know.  They are in the midst of a budget crunch. [8344] yeah, maybe, have to see how finance pan out [8345] robin_sz: hope you can make it [8346] if I have the cash I will, It means I have to sell another machine though :) [8349] Looks like I will be there (as long as Imigration let me in). [8350] I can't bring a machine, but I have a testbed with a 3 chan Xylotex drive, power supply, and a jog wheel that I'll bring along [8351] oops - three motors too [8352] jmkasunich: Good. I've got two Sherline mills with one fourth, a sherline lathe, and two Grizz if we need them. [8353] I can bring other stuff too if there is a need - oscilliscope, misc electronics stuff, spare steppers, etc [8356] I'm certain that we can use the Smithy stuff as well. [8385] Sounds like we have plenty of equipment and several folk for at least Monday through Wednesday. [8391] time for Rcslib ? [8392] ok [8393] Does emc2 need it ? [8394] My summary looks like April 23-25 for NAMES, 26 for EMC Monday, and 27-28 for the EMC HackFest. [8395] 4/23 is Friday? I thought NAMES was Sat/Sun [8398] sounds good to me - Should be able to make all dates. [8399] Right.  Friday is setup day and student tours. [8400] oh [8401] I get there on Wednesday and help set up the space and make certain that "we" have enough juice. [8402] I have a conflict on the weekend.  I'm committed to Sunday, Monday, and beyond, but Sat is iffy, and Friday very unlikely [8405] No problem with me. [8406] Let me ask the question, "Why would EMC2 not need rcslib?" [8407] less code to debug. [8408] And RCS lib seems to be the part of EMC that keeps getting more complicated as NIST adds features for new projects. [8409] that's why we don't _want_ it...  but we might _need_ it anyway, or at least part of it [8412] it was suggested last week that EMC doesn't need rcslib, and a standard posix IPC would suffice. [8413] Could you explain posix IPC. [8414] The R in rcslib is supposed to stand for realtime isn't it? but none of it is really realtime [8415] very basic: Shared memory and semaphores to share data between tasks running on a single computer. [8416] the posix bit just defines a basic set of rules for syntax and performance. [8419] does posix IPC handle multiple boxes, or _only_ a single computer? [8420] RCS - Realtime Control System [8421] posix IPC is for local tasks, not networked apps. [8422] so does that mean we still need rcslib for networking? [8423] or something capable of handling n/w comms [8426] in emc, is it true that we have _no_ realtime network stuff [8427] but then... How many people are using EMC across a distributed system ? [8428] we need to keep support for remote GUIs at least [8429] (tho you should be able to do that with an X server and client) [8430] which you could use VNC for.. [8433] or ssh -X [8434] so there is a fundamental question: Does EMC2 need to support networking/distributed systems?? [8435] however ... we do actually have rcslib already, in a paul_c hacked down to size format .. [8436] that is currnentl borked. [8437] ahh, but you have put a lot of work into it .. [8440] I'd say that we do need network. [8441] which will save time as I backtrack to find the problem area... [8442] It was the intent of NML to be able to predict transmition latencies that works a bit like Nyquist type installations. [8443] I can't say how well it does that.  There is a NIST paper on it. [8444] do you mean 'networked' as in GUI networked or 'different bits of the machine' networked? [8447] ray_: how would EMC use that capability (I need a real world example to understand where you are going) [8448] retaining rcslib/nml does leave the door open to stepNC being brought on board sometime in the future. [8449] tbh, I can see the former being used in 10% of installations, the latter in <1% ... [8450] stepNC noted [8451] Example might be distributed control of motion. [8454] axis X & Y on one PC, Z on another? [8455] (even if XML sucks as a way of transmitting data) [8456] ray_: but can you actually see more than 1% of installs using that? [8457] Where more than one PC controlling motion needs to know what the other is doing. [8458] as in work cells with robotic arms ? [8461] Probably not but I've got an engineering friend at G&L that built a mill the size of a US football field. [8462] I'd settle for emc being able to one thing well ... none of us are likely to build robotic work cells are we? [8463] tool changers ? [8464] That would be a place where Nyquist type distributed motion is essential. [8465] box A controls mill, box B controls arm, they can communicate at a high level (mill: "I'm done cutting, change the part", robot: "OK, part changed, start cutting") [8468] likely to be RS232 controlled no? [8469] robin_sz: I am. [8470] or how about interfacing to a G2003 [8471] When I visited with Hugh (A MatPlc guy) he has a 12 station work cell running with Linux. [8472] G2003 would be a HAL periphial - it sure as hell won't be running RCSLIB [8475] should have the same i/f as any other emcmot plugin [8476] IMO g2003 is a dead horse. [8477] ray_: depends on the app - imo it will give Jon E [8478] oops [8479] ray_: essential for steppers [8482] will make Jon E's boards obsolete (unfortunately) [8483] jmkasunich: I understand what you're saying. [8484] sadly so, but its a better solution I fear .. [8485] The problem is that to much of the computational load must be transferred to the rabbit. [8486] right - the G2003 pulse generator is better, and Jon can't hope to match Mariss's manufacuring costs [8489] ray_: forget that argument, its lost. it actually works [8490] ray_: I would use it in dumb more [8491] mode [8492] That done, to much of the flexibility is lost to the EMC. [8493] ray takes a breath. [8496] in dumb mode, it's just a fast, cost effective step generator, flexibility is retained in EMC [8497] we did this weeks ago, in dumb mode its fast and flexible [8498] nods [8499] the "other guys" are focused on smart mode cause they have to fight their OS for realtime, and they see smart mode as a way to get away from that [8500] in smart mode, rcslib/NML would help in controlling several at once. [8503] again though, each one is 6 axes ... [8504] the CPU on the G2003 can't do rcslib - it's only a Z-80 [8505] how many real world applications will need more than 6? [8506] jm said "G2003 would be a HAL periphial - it sure as hell won't be running RCSLIB" [8507] so PC runs rclsib and chats to the [8510] And yet inter-axis communication needs real time. [8511] which you will never achieve with USB. [8512] ray_: yes, you've hit it on the head...  IF you want axis on more than one PC, then you need RCSLIB [8513] It seems to me that we need to figure out if RCS/NML is a help or an hinderance to getting EMC2 working. That seems most important in making further progress toward and operational EMC2 system. [8514] Or at least the ability to predict latencies between coordinated processes. [8517] but my question is why would you put multiple axis on different PCs? [8518] Distance?  Because we can? [8519] I can see putting sets of co-ordinated axes on differetn pcs, (eg robot arm on one PC, router axes on another_) makes sense [8520] distance is a valid reason (maybe).  Because we can isn't [8521] Look at some of the multiple milling heads working in cooperation. [8524] but coordinated axes split across pcs is a bit ... esoteric [8525] Till and the Ocean projects have been studying this for several years. [8526] We've got cooperating Humvees out in the desert. [8527] well sure ... but what do you actually NEED? ... from emc2? [8532] I guess its a matter of perspective - I see EMC2 as a project built, supported, and used by hobbyists and geeks, not as a corporate or government project with a bunch of PhDs... [8536] I'd settle for something that controls a 3 axis mill abolsutley *perfectly* rather than soemhting that had the facility to control multiple synchonised humvees [8540] And therein lies the fork. [8541] quite [8542] so emc as it stands is all thing to all men (although some of the things are a bit dodgy) [8543] ...and don't you guys start arguing either!! [8546] emc2 should be more focussed on what real machinist want from it in the real wolrd [8547] mshaver: too late [8548] well, be right back, sorry I'm going to miss some of this, looks, uh, contentious... [8549] you brought the subject up... [8550] for instance:  the new traj planner.  It has been stated that there is some bug that nobody will be able to fix until the original author has a change to work on it [8553] that kind of thing is a problem - if this is to be a true open source project, the source has to be understandable by more than one person [8554] nods [8555] oh lord, going to pray now... [8556] thanks matt, we need it! [8559] unless your $deity is any good at harcore C/C++ it may not help ;) [8562] aside from remote GUIs and Humvees.... rcslib does provide potential for one application used widely in industry [8563] right [8564] do tell [8565] now ... what is it? [8566] remote logging of machine statistics and status. [8569] ahh, yes .. [8570] does that NEED rcslib? [8571] and therefor diagnostics [8572] jm wrote  not as a corporate or government project with a bunch of PhDs... [8573] doesnt think it does [8576] Trust me on this, we've got lots of both kinds hanging round our lists. [8577] I want an industrial grade package, not anothe Tcnc or Mach2 [8578] sure ... look, I have no real problem with rcslib, just so long as we keep in perspective what we are trying to achieve [8579] right [8580] that _might_ be a good thing (excuse my skeptism about PhDs - I work with a couple - they need keepers/translators to provide a realworld filter) [8583] I know of at least three that are using EMC for their personal machines. [8584] so... A quick show of hands - Those in favour of keeping rcslib (in one form or another). [8585] nay [8586] Yes. [8587] isnt sure either way [8590] Fine either way, just don't let hold up progress on EMC2 and HAL. [8591] I believe Matt is sitting on the fence for this one.. [8592] I don't think this is the real issue. [8593] on the one hand it provides useful facilies, on the other the interface sucketh [8594] I think the real issue is that some feel the need to understand all the code at one time. [8597] actually I'm on the fence too... show me a must have feature that can only be implemented using rcslib and I'll change my tune [8598] ray wrote: some feel the need to understand all the code at one time. [8599] that will never happen [8600] Does the RCS and NML code suffer from the same abundance of dependence on global variables that EMCMOT does? [8601] IMHO we need a team approach. [8604] but I do feel the need to be able to pull a piece of code out and completely understand it [8605] that means minimal cross coupling between pieces [8606] if rclib was one of htose 'look its so amzingly simple, I just chuck messages in here .. and they pop out here' libraries that actually made the coding easier, I;d say go with it .. but the interface sucks harder than an electrolux [8607] and whatever coupling there is needs documented [8608] rcslib doesn't have as much globals [8611] it currently has a horrible mess of 'classes' releated to NML wrapped up with it thuogh ... [8612] although thats slightly another topic [8613] NML by it's self is very simple... [8614] but? [8615] it's the rcslib/CMS cruft that makes it look worse than it is. [8618] well it certainly was enough to put me off [8619] so .... ? [8620] well... I'm in favour of keeping rcslib - It makes the task of re-working emc2 much easier... [8621] You folk are so way beyond me in this programming business that when things shake out, I'm at your mercy. [8622] But a couple of thoughts.  Why re-invent the wheel even though this one may be bent a bit. [8625] ray_: but your input is still important.. keeps us pointing in the right direction [8626] ray_: because that particular wheel is so badly bent its shaking the whole wagon apart, but we make keep the hub, and just put new spokes and a rim on it. [8627] ray_: we're not beyond you, just different.  I for one am very good at low level stuff, but the GUI stuff makes me batty [8628] My programming consists of a few commands, thrown into the black hole with the hope that they do what I intended. [8629] You guys are working on the balck hole and that's essential. [8632] you have a much better understanding of the GUI and command/message interface than I ever expect to have [8633] jmkasunich: or that I'd want you to have. [8634] This is the team thing. [8635] i dunno about that - there are certain big picture concepts that everyone has to grasp in general terms - messages and commands are one of them [8636] Now I think that we are getting to the issue. [8639] Yes.  We all need to understand the big picture.  And the place of each central developer in that. [8640] What I've seen of the rtapi is awesome. [8641] It has shifted the whole issue of keeping current with evolving real time into one place. [8642] What little I understand of the HAL layer says to me that this will be THE answer to all of my hardware problems. [8643] right ... which comes back to waht i was sayin earliuer in the week ... [8646] we now have several parts of the picture .. bet we don;t as yet ahve a great plan for sticking them together [8647] thats what we need next [8648] yep [8649] (and we may have some overlapping bits of picture when we sort out our plan) [8650] in other words - the "big picture" [8653] so how do we get there? [8654] Steve said, "Fine either way, just don't let hold up progress on EMC2 and HAL" [8655] I think that this is the central point.   [8656] what's holding me up is finishing hal_scope.  I think it's a vital tool for testing other hal components, and for integration with emc proper [8657] If the rt side of HAL is ready, then let's begin to build the user space stuff that can take advantage of it. [8660] I have a list of other hal components I want to build - some will go rather quickly [8661] ray_: hal is both rt and user [8662] right. So ... lets get to the crunch ... HAL is lovely, and extensive. More extensive than some of us had originally imagined. However, since its so neat, I think its worth considering how best to use it as a framework for perhaps more of emc than we first though [8663] t [8664] what hal is now is something that can take a set of coordinates (one per axis) and move motors to match those coords. [8667] it can also make external signals available - for example from a pendant [8668] I'd like the user interface to read as many of its inputs from hal pins as possible (primarly those that are a single number or boolean) [8669] So let me be devil advocate.  Why can't we connect it to the interpreter and run a machine like we can with the old system? [8670] define "we" - I don't understand enough of the old system to even begin doing the connections [8671] probably the ext_ interface could be used though [8674] the interpreter is not a realtime component [8675] If I can now send position commands to a set of axes. What would prevent me from doing that with EMC@ [8676] interpreter feeds traj planner, which spits out coordinates.. ( I think ) [8677] what happens to those coordinates next?  are they ready to go to PID loops, or is there a bunch of other logic, like homing, etc. [8678] And here interpreter ---NML--- Traj ---NML--- usr space SHMEM module. [8681] Or is my picture to simplistic? [8684] interp --NML--> traj --NML--> user space? --??--> PID --velocity command--> motors [8685] but what is the usr space shmem part? [8686] interp and traj are both in user space? [8687] NML is only used to communicate between seperate programs [8690] i.e. between bridgeporttask and bridgeportio [8691] and the GUI [8692] We really are talking about the glue that allows the whole thing to cooperate. [8693] Yes we could build a monolithic executable and eliminate the connectors.  Then we [8694] 'd have something like all the other hobby programs. [8697] don't want to go there.  HAL is a move in the opposite direction - hal and nml are both glue [8698] Good thought. [8699] hal is realtime/user glue that passes simple data like numbers and bools within one machine [8700] nml (if I have it right) is non-realtime glue that passes complex data like messages or structs, and can go between machines [8701] So if we keep NML we need to build a translator from it's structs and messages to the HAL module on the user side. [8704] hal passes stuff that is updated more-or-less periodically - nml passes stuff that is non-periodic [8705] pretty much - Data (either one bit or a struct of floats) is encoded as a simple message and passed around.. [8706] well not quite that simple [8707] for instance, I think emcmot would get a nml message that represents some cannoncial motion command.  it doesn't just pass that to hal - it executes the command, and passes a string of positions to hal [8708] Good.  I can fit that into my picture. [8711] We have to be careful thinking of emcmot as a single thing however. [8712] Mixed a few lines here... NML is just a method of passing messages in user space. Nothing more. [8713] ray_: you mean emcmot = steppermod, freqmod, and all the rest? [8714] Thinking back to the first EMC Monday..... has anyone ever managed to create the magic diagram showing the data flow through EMC? If we could pass out an electronic version of such a diagram it would help a lot in explaining ourselves. [8715] I've spend the last few minutes in a fruitless search for the block diagrams that I posted back in april [8718] (pretty sad when I can't even find my own webpages) [8719] A graphical representation of the big picture. [8720] jmkasunich: was that the page pulled by your ISP for innappropriate content ;)) [8721] http://home.att.net/~jmkasunich/EMC_Docs/EMC_Home.htm [8722] yeah, that one [8725] :) [8726] so ... is that still 'correct' or has HAL gone somewhat furthr up the lefthand side of figure2? [8727] notice the detail at the bottom, and the big empty boxes at the top - that accuratly reflects my understanding of emc ;-/ [8728] http://home.att.net/~jmkasunich/EMC_Docs/EMC_Control_LG.gif - Small correction to the left hand side.. [8729] the EMCTASK <-> SHMEM comms is handled by usrmotintf.c [8732] and never sees NML. [8735] so .. what was this talk of PID hal components etc ... [8736] that does not seem to fit with fig2 [8737] hal is reaching a little higher [8740] PID is software and has nothing to do with hardware [8741] "Unit Convert" should be part of the HAL layer, but not outside of it. [8742] paul_c: I dont see that as a distinction, it just a question of where in the framework to put it, and if PID can blend in as a HAL component, the fine, so long as we all know where we are going .. [8743] whats important it that we dont duplicate effort, or it will be wasted, and we have precious little to waste [8744] to my mind, PID fits well with HAL, its just a 'motor' you ask it do go to somewher, it tries to go there and tell you where it is as it does it [8747] I dont see a problem if it sits on the other side of the HAL wall api, do you? [8748] notes it has all gone quiet [8749] I do. [8750] well speak up then :) [8751] The ouput from the PID calc is used later in some extra following error calcs [8754] (used as error checking for other parts of emcmot) [8759] paul_c: the "output" from pid calcs you refer to is the error? [8762] or the velocity command? [8764] the difference between the *now* position and the *Target* position is the basic error [8765] right [8766] IIRC that is a pin of the PID hal component - if it isn't, it can be [8769] Because this error is traversed in one time slice, velocity is implied. [8770] the error is not neccessairly traveresed in one slice [8771] PID is applied to the "error" and then checked against the allowable following error. [8772] if the Now-Target error is not completed in one time slice, it gets added to the next calc. [8773] yes ... but, surely that can be still handled on the hal PID no? it just reports back the current error no?? [8776] error = desired - actual [8777] is obviously missing something [8778] velocity command = PID(error) [8779] velocity command is sent to the motors (or stepgen, or whatever) [8780] right .. thats how I understood it .. [8783] error is compared to the following error limits to decide whether to fault or not [8784] and that can be a HAL pin [8785] right [8786] so the PID does axactly what it always did, except it s a pluggable HAL module [8787] right [8790] S you'd have another HAL config entry for the error feedback ? [8791] yes [8792] so slapping in other strange variants of PID would be trivial [8793] right [8794] just checked the source, error is already a pin on the PID hal module [8797] Does any other part of the RT system need to link to this "error pin" ? [8798] in a way, that makes sense, because PID values are 'hardware' really [8799] dunno - you can scope it or meter it for troubleshooting [8800] but I don't know if any other part of emc needs to see it... [8801] doesn't matter, if they need to see it, they can [8804] hal shouldn't be viewed as a wall (a term robin used earlier) [8805] it is the equivalent of an electronic breadboard - you install components, then connect them [8806] if a needed signal exists on a component pin, then it can be connected to any other component pin [8807] How much more of EMC would you convert to HAL components ? [8808] suspects 'most of it' [8811] that is subject to discussion - I would convert a lot (not most robin) [8812] I didnt mean that as a bad thing btw [8813] if the breadborad approach is working .. [8814] anything that periodically evaluates a more or less fixed set of inputs and makes a more or less fixed set of outputs is a candidate for halification [8815] might be all we need is an edge connector for the GUI [8818] things like auto/manual switches, feedrate override knobs, etc, can be halified - they can come from physical devices on a pendant or from the screen [8819] Would you make the Trajectory Planner a HAL component ? [8820] things like MDI and selecting the g-code file are more complex and would avoid the HAL [8821] sure .. thats all on thje GUI side ... [8822] don't know about the TP - it's outputs are periodic, but its inputs are not - I don't really understand what it's inputs are [8825] I'd like to - it would enable the TP to be swapped in and out [8826] but might not be practical [8827] Trajectory planner abstraction layer was mentioned at EMC Monday as another topic and NIST mentioned having some internal reason for considering it. [8828] kinematics are definetly a candidate for halification [8829] That is bloody lunacy ! [8832] why? [8833] really? [8834] seems ideal to me ... [8835] the 'hardware' appears as x y and z [8836] inputs: position in machine coords,  outputs: position in joint coords [8839] HAL was touted as a Hardware Layer NOT a glue to stick bits together. [8840] The NIST requirement was related to distributed motion control and having different update rates for servo loops. [8841] paul_c: but if it appears to be good glue ... [8842] like I said, it's subject to discussion - I personally think it works as glue [8843] Some type of HAL might function as glue for other parts of the system, but functionally it would be a different "layer" of interface. [8846] I understood it to be a way of assigning (for example) parallel port pins to step/dir outputs. [8847] hal is glue that was originally designed to glue hardware to software, but also works for software to software [8848] personally I;d have liked to have seen a more C++y sort of component structure, bigger lumps made from inheriting or compositing smaller lumps, but .. i didnt get off my ass and write it so .. this glue seems OK [8850] robin_sz: like a hiercharcal (sp) schematic in electronics... [8851] sort of .. [8854] components made of simpler components but used as if they were monolithic [8855] I imagined a backplane .. [8856] things plug in and announce what signals they will listen for [8857] signals can be sent, and maybe they find a listener [8858] maybe they dont [8861] right [8862] thats sort of how it works [8863] which reminds me [8864] last night I committed a simple hal demo [8865] it's in the scripts directory of the emc2 tree [8868] right [8869] the first one is very simple - just loads the parport module, and jumpers an input to an output. [8870] the script does it step by step [8871] so even thickies like me can understand it? [8872] I think playing with that will make things clearer for everybody [8875] I will add another more interesting demo asap [8876] problem is a lack of signal sources - most people don't have jog wheels or spare encoders handy [8877] the fact that you were able to trivially add a handwheel and connect it to a motor speaks for itself imho [8878] what I want to do is have a demo that lets others do the same, and see firsthand how it works [8879] so where does all that leave us? [8882] confused [8883] ;-) [8884] so.... Why can't I connect the output from the encoder to a parallel port pin ? [8885] you mean from a real encoder? you can [8886] I have my jogwheel hooked to pins 10 and 11 of my parport (input pins) [8889] OK... The output from jogwheel. [8890] then I route those pins to the hal encoder module which counts the pulses and produces a number on another pin [8891] (a HAL pin, not a parport pin) [8892] that number is routed to the position command input of the PID loop [8893] OK... Rephrase the Q... [8896] the velocity command output of the PID is routed to the frequency input of the stepgeh [8897] OK [8898] so.... Why can't I connect the output from the encoder HAL module to a parallel port pin ? [8899] cause the output of the hal encoder counter module is a position count.  you can't connect a number to a single pin [8900] because its a count (hence 16 or 32 bits wide) and a pin is 1 bit wide? [8903] right [8904] If I wanted an indication of a zero value... [8905] youd need a 'comapare to zero' hal module [8906] you mean a bit that goes true when count = zero [8907] True = Non-zero [8910] just needs a HAL component, 32 bits in, 1 bit out, some wierd magic in the middle [8911] either a module like robin said, or add the compare to the encoder count module and give it another pin called "encoder.1.non-zero" [8912] the comparator module would be more general, adding the code to the encoder counter would be marginally faster and simpler to configure - you pick the path based on your needs [8913] more bits to wire up. [8914] the third alternative is that the component that wants to know if it is non-zero hooks to the number and does the compare internally [8917] its just the same as using a cast, you cant normally interpret doubles as bools without defining how you expect them to react [8918] but on a breadboard, I can wire th output of an opamp into a schimtt trigger [8919] 1 wire .. to 1 wire ... [8920] yes .. and? [8921] right - the comparator module robin described is a schmidt trigger [8924] 1 analog wire to 1 digital wire [8925] right, understood [8926] I dont see this particular artefact as ebing a major problem ... [8927] or replace the schmitt trigger with any other Logic block. [8928] If we are going to make the comparitor useful, I think it needs to consider the magnitude of the error as well as whether error is zero. [8931] the hal interface is light and fast enough that you _could_ go as simple as modeling individual comparators, summers, limit blocks, etc.  but larger functional block will be easier to configure, though less flexible [8932] A comparator module would be one solution - But what happens if you ned 5 or 20 ? [8933] I would do a comparator with two inputs A and B, and three outputs, A>B, A=B, and A just like real electronics [8935] insmod comparator cfg=20 [8938] would give you 20 comparators [8939] comparator.1.input-A would be the input of comp #1` [8940] parport, encoder, and stepgen work that way already [8941] but I'm not advocating such fine grained modularity [8942] The three outputs doesn't tell if the process that is attempting to sum to zero is gaining or loosing ground. [8945] the PID block is an example of coarser grained modularity. [8946] ray_: then use the raw data, eg like in the PID block [8947] ray_: the 'comparotor' was purely to satisfy paul_c's 'how would I ...' question [8948] it consists of a summer to create the error signal, an integrator, an differentiator, several multipliers for the gains, and a summer to combine the output terms into a single signal [8949] you could build it from the inidvidual pieces, but it would be somewhat slower and more work to configure [8952] Okay. [8953] I want "method" not "policy" at the low level. [8954] I do plan to make a set of primitive components, just to play with and to enable custom stuff [8955] I'm fuzzy on method/policy [8956] can someone explain it again [8959] Method is like handing you a bunch of 4mm patch leads to wire up your mill. [8960] Policy would be to give you individually terminated leads that would only conect point A to B [8961] I see - hal is method [8962] So if you needed a 4 pole relay, you'd also need a new connector. [8963] like handing you a drawer of ICs, ranging from a 741 op amp to a 7166 encoder counter, and a pile of wires to hook them together [8966] 'cept you are providing different wires for different signals. [8967] sure [8968] just like real life [8969] when just one type of wire could be used instead. [8970] single wires for power, multicore for data? [8973] in real life you don't connect mains voltage to op amp inputs [8974] its not the wires that have types - its the pins [8975] right [8976] digital (boolean) connects to digital, analog to analog [8977] jm wrote, "insmod comparator cfg=20" This suggests a kernel module that accepts 40 signals and outputs 20 results. Does it also suggest a whole pile of kernel modules? [8980] But I could still connect an analogue input to a digital output. [8981] only one module, with 20 structs, each containing info about one comparator [8982] paul_c: well yo ucold, but the results would be undefined [8983] But every separate rt task would have it's own module? [8984] Class D amp [8987] paul_c: ideally, the wires should have plugs to stop you doing that [8988] sounds like labview g code. [8989] paul_c: we need to make some concessions to the computer - in C, a boolean is false if 0, true for _any_ non-zero value [8990] paul_c: a class D amp would have a anologue in and out, ie double and double, [8991] ray_: most hal modules don't actually define tasks, they just make functions available [8994] some (or perhaps only one) modules define tasks with specific periods (like the servo period, or a faster period for stepgen) [8995] then you can tell hal to evaluate comparator.1 in the servo thread, and evaluate comparator.2 and .3 in the stepgen thread, or whatever you need [8996] I kinda see what you're saying. [8997] I can see both sides, [8998] I can see how it doesnt perhaps fit in with paul_c's view of how things could be done [9001] goes for some vit. N [9002] but it also seems to be flexible and expandable [9003] Well, you're all still here... that's good! [9004] Perhaps task is not the correct word for it.  What I was seeing is an encoder module passing data to a PID module and teeing that output to a stepgen module and a comparitor module.  Sounds to me like lots of modules. [9005] could be [9008] that's why I wasn't going for very fine grained modularity.  I would expect that the following error detection logic would be part of the relatively big emcmot module [9009] mshaver: to bring you up to speed, so far we have two black eyes, a couple of minor head wounds and a stretcher case, but no fatalities [9010] so no comparator [9011] although the ferror part might make a nice module overall [9012] jmkasunich: a sort of error and velocity in, true/false out ? [9015] inputs: axis velocity (so it can compute velocity dependent ferror trip point) and error (desired-actual) - output would be a boolean fault [9016] so ,,, [9017] That's pretty much the way it is now, isn't it? [9018] as I see it ... all that we need to do is figure out how to connect an interp, a GUI and 'some other stuff' ? [9019] actually, inputs could be desired and actual, it would compute velocity internally from desired and old_desired [9022] ray_: what is different is that the modules are separate, and interact _only_ through their pins [9023] I talked to a couple of guys about making CNC gear hobs using EMC and I'm trying to get my head around how EMC@ might handle that. [9024] so they can be tested and debugged independently, and have no strange side effects [9025] oops. [9026] my todo list for the next couple days:  add a signal generator component, add a few primitive components (comparator, summer, and gate, or gate), and add some more demos [9029] While I was away, did we answer the question, "How can we help EMC2 along?" [9030] robin said:  all that we need to do is figure out how to connect an interp, a GUI and 'some other stuff' ? [9031] that is the rub - I know hal, but don't know where to start on the rest [9032] everybody else is still learning hal concepts (but I hope the demos will help) [9033] Interesting little experiment... Connected 240V mains to a 7400 gate. [9036] poof! [9037] It blew up in my face, but I only have myself to blame for that. [9038] Perverse is to kind a word! [9039] what did that poor 7400 do to deserve such a fate? [9040] just another input pin on the breadboard. [9043] robin_sz: Sorry, was reading back as far as my buffer goes... [9044] sounds like paul's not so thrilled about the breadboard analogy [9045] It's the retrictions on what pins can be linked together that I have trouble with. [9046] you don't like typechecking in C either? [9047] and modularising everything for the sake of it... [9050] I can perform logical operations on an Int or a Bool value in C [9051] jmkasunich:as fas as hooking up the other stuff goes, I visited fred the other day (you wrote to ask how it went) and we rtapi-ified emcmot.c. I sat down last night and started to figure otu how to make it into a hal component. When done you should be able to command a new axis position and see your motors go thru the acc-steady-dec trapezoid. [9052] and add a Char to a Long. [9053] paul_c: yes, you can do those things, but C does type conversions for you - the char is sign extended before adding it to the long [9054] paul_c: yes, because C has rules about implicit casts. [9057] mshaver: That sounds like a direction. [9058] hal handles raw data - if you want to mix types, you need to translate them.   [9059] neither the source module or the destination module should be burdened with type conversion code [9060] paul_c: it is worth noting that the gnu coding standards reccommend that you do all casts explicitly eg. (float)my_int rather than relying on the compiler to get it right. [9061] true - But an Int can be used to represent a Char. [9064] (this is a form of linking - when one C source file declares "extern int n" and another declares "long n", they won't link [9065] paul_c: in some languages, yes ... but in others a char, is a char and an int is an int, [9066] so you'd use a data type that could be used to represent both an int and a long. [9067] moot point about languages - RT code MUST be C. [9068] so what about floats - should we allow a float pin to connect to an int pin? [9072] perhaps the hal need a "cast" function. It could follow a fixed set of rules. [9074] right now hal has bit, float, and 6 integer types, s8, u8, s16, u16, s32, and u32.  I can see where maybe all the int types should be merged into a single int type.  But I have real problems with float<->int and even with int<->bit [9075] I see no reason why linking a float pin to a bit pin shouldn't be "allowed". [9076] If (or rather when) it blows up in the user's face, only one person can take the blame. [9079] so what value of floating point number will make the bit be TRUE, or FALSE [9080] non-zero is always TRUE [9081] and when going the other way, what float number should you get  when a bit is TRUE [9082] one [9083] or Not-Zero [9086] what about bit->int, should that result in 1 as well? [9087] not-zero is not a floating point number [9088] but zero is. [9089] zero = FALSE [9090] right - a false bit could be represented as 32 bits of zero, which would be 0.0 if a float and 0 if an int [9093] therefor, any non zero number will be TRUE [9094] that covers float->bit, not bit->float [9095] you can't interpret an arbitrary 32 bit value as bit, float, and int and get sane results without some conversion code. [9096] It's been fun -- and profitable.  Thanks.  I'll look for the log and see what I missed. [9101] so ... is that the end of round 2? [9102] dunno... ;-) [9103] Aside from the type restrictions between HAL pins, I have serious concerns over the desire to modularise EMC and make it subserviant to HAL. [9104] that is a more important point anyway... the degree of modularization is a grey area [9105] I think modules should be small enough to be understandable [9108] that does _not_ mean reducing everything to tiny primitive modules [9109] to my mind, there are three clear levels where things *shuld* be seperated. [9110] physical hardware (which is where HAL fits in) [9111] the kernel(or realtime) boundry [9112] is a step generator physical hardware?  if it's part of Jon's USC, yes, if its done in software, no - in both cases the hal is the appropriate interface [9115] sorry for the interrupt - third one is? [9116] interprocess comms in user space - This is where rcslib fits in. [9117] maybe we're gonna have to simply agree that we disagree on this [9118] an example: suppose you have a pushbutton on a pendant [9119] its wired to a parport pin, and thus is available in the hal [9122] you want the button to do something when the operator presses it, perhaps estop [9123] maybe not estop - that's a special case [9124] anyway, suppose you also have a button on the GUI [9125] (select a menu option perhaps) [9126] they are both buttons - one is hardware, one is software and very much user space [9129] my approach would be that both drive hal pins [9130] both should act in the same way then ... generatign the same message into the 'core' ( whatever that might be) [9131] or should the HAL layer send messages back out when the button is pressed [9132] and if the GUI is running on a remote computer ? [9133] would the button still talk directly to the HAL ? [9136] it could [9138] let me ask the inverse question - today, how can you use a physical button (on a pendant) to do something that a GUI button normally does? [9139] I can email the log [9140] I would have HAL send a message out from some sort of 'actor' that says 'when this pin goes hi, I send out an pauseButtonPressed message' [9143] robin_sz: hal itself wouldn't do that, hal is just a pool of pins and sigs. [9145] well something connected to a hal pin then [9146] but a hal component can easily be written that sends NML or other message when a pin changes state [9147] or conversly drives a hal pin when it receives a message [9148] but HAL should have no knowledge of NML [9151] right [9152] only the translator component knows about nml [9153] ok, that makes sense to me [9154] that is a sort of bridge between NML space and HAL space [9155] normally that gap would be spanned by a higher level object, [9158] but a simple translator could exist too I guess [9159] my lack of knowledge about NML and today's GUI is hurting me here... when you press a GUI button, does that send a NML message, or does the GUI do the work itself? [9161] its a two way thing [9162] the GUI buttons either control IO or emctask [9165] (not quite true) [9166] via emcsh ... [9167] and ... [9168] the GUI issues NML messages which the IO controller or emctask picks up on. [9169] ok, I need to retract my comment about the GUI directly interacting with HAL [9172] I thought the GUI called emcsh embeded functions, which generated NML messages [9173] but I still think pendant controls should come in thru the hal, then a hal->nml translator [9174] there are commands within iosh that operate directly on IO [9175] sounds about right [9176] The emails lately about a PIC sending pendant button presses serially directly to the GUI bothers me.  Those should go thru the hal [9179] yes [9180] indeed [9181] no [9182] after all, what if you have spare dig ins on the parport, or stg, or whatever.  you should be able to connect pendant items to those [9183] a button on a pic at the end of a serial port is no different than a button on a stg digital input or a parport input [9186] ? .. the HAL module should be responsible for issuiing NML or whetevr, that corresponds to whatver codes come in from the pendant .. [9187] USB and Serial ports are non-realtime [9188] so? [9189] so? [9190] a button is a button [9193] HAL is in kernel space, right ? [9194] jmkasunich: I think ray just wants to prototype the serial pendant that way, not leave it connected to the gui as the normal way of doing things. [9195] nods [9196] mshaver: yeah [9197] hal is not just kernel.  the API allows user space processes to export pins just like kernel modules [9200] I can see how you could just plug in a HAL module to handle the serial and trnaslate it to NML or whatever, different pendandt, different plugin [9201] eg, if we had a G2003 module we may not even *need* any realtime support ... [9202] I would go serial<->HAL with one driver, then HAL<->NML with another component.  both could be user space [9203] but that doesnt mean no HAL .. [9204] hell, we could even do a windows version then ... [9207] ducks .. [9208] ick! [9209] preps the 75mm cannon [9210] sorry, [9215] speaking of the G2003 - it has 16 general purpose dig inputs IIRC - why shouldn't they be used for pendant controls? [9321] well, i'm going to read over the log & ponder the junction between HAL pins and NML messages because that's an issue wint emcmot.