-------------- Original message ---------------------- From: "Peter C. Wallace" <[EMAIL PROTECTED]> > > (It would be nice if could email you directly (all my emails bounced)...)
Yeah, it would. I have another email address, jmkasunich at yahoo.com Could you send me the bounce messages to that address? Maybe I can figure out what is going on... if ATT thinks your ISP is hosting spammers or something they might have it blacklisted. They did that to Sourceforge a while back and it was quite annoying. ATT and SF were both pointing their fingers at the other guy. > I was lurking on the EMC IRC channel (mainly lurking because I cant figure > out > how to use my IRC client) and noticed you had a problem with the 3.3V outputs > on the 5I20. > > The problem comes from driving an opto isolater powered from 5V with the > 3.3V output of the 5I20, The opto isolator will have a ~1V IR LED forward > drop meaning that even when off you have about .7V/R_series current going > into > the LED, leading to marginal operation. Right. For the real thing I'll be buffering it, probably with a 74HCxxx Running on 5V they will accept 3.3v logic on the input, and produce rail-to-rail 5V swings on the output. I'm old school - I like 5V logic and +/-10V analog signals, with +/-15V supply rails for the analog circuitry... Actually after further testing I figured out that its not the voltage levels at all. Average latency on this box is about 1.5uS, but values of 15-20uS are not at all uncommon, and the worst case when I did a few minutes of latency testing was 31.7uS. I was running at 20uS period for the software stepping. When latency is as long as (or longer than) the period, you get very short (about 2.2uS) steps or spaces between steps. A 2.2uS low time is no problem for the Gecko, but they spec a 4uS high time. Changing the software step generator's "stepspace" parameter to 2 fixed the problem. (A value of 2 means that there will be at least two periods between step pulses.) Lengthening the period from 20uS to 30uS also solved the problem. But both solutions lowered the maximum step rate from one step every 40uS to one every 60uS. The motor and drive are capable of dealing with one step every 10uS, so hardware stepping is the way to go. > This is also a problem when used with I/O module racks with 5V input > modules. There is a very simple solution (which is in the 5I20 manual): > > Use the outputs as open drain, then they can swing all the way up to > 5V when off (there are 3.3K pullups on the card). > > For the I/O configurations, this just means setting the assosciated output > bits low, and outputing your signal via the Data Direction Register. The existing HAL driver for the digital ports doesn't support that unfortunately. That can be changed of course - I just need to make the time to do some serious hacking on the driver. We have canonical interfaces for things like encoders, digital ins and outs, etc. and whenever possible we try to make the drivers match those interfaces. That way when somebody switches from parport digital outs to 5i20 digital outs, they work the same. Likewise when they switch from software encoder counting or step generation to hardware based functionality. The existing driver doesn't match up to the canonical interfaces very well, probably because at the time PeteV was doing the driver, the canonical interfaces were poorly defined and in a state of flux. For the next round of driver changes (including the step generator), I'd like to get the driver to emulate the canonical interfaces as much as possible. I'm planning on making the time to redo the driver as needed, and in some cases modify the FPGA firmware as well. At the moment there are features in the hardware that the driver doesn't use, and probably features the driver would like to have that aren't in the hardware. By the way, the canonical interfaces are described in chapter 4 of http://linuxcnc.org/docs/HAL_Documentation.pdf One thing we don't have in the canonical list is a digital pin that can be either in or out. Pete's driver exports 32 inputs and 16 outputs. I guess that means two of the cables are digital I/O, and all the encoder/dac stuff is on the last cable. (For some reason I was thinking that the encoder/dac stuff occupied two cables.) The default pin config matches the 7i37 card, so that makes sense. But it might be nice to be able to configure them in other combinations. We need to come up with a preferred way to do that. The normal HAL approach for something like that would be to make the mapping of ins and outs be a load time parameter, so as the driver is loaded it would export the relevant HAL pins. Deciding if an output is normal or open collector or tri-state could either be done at load time or run time, I'm not sure which would be better. > I will add this capablity (open drain 5V outputs) as an option to the > hardware step configuration. > > BTW I have made a non-buffered hardware stepgen configuration (free running > DDS) with somewhat klunky but flexible dir-->step-->dir setup/hold timing. I > will test it tommorow. If we can solve the email problems, I'd be happy to do some testing here too. Got everything set up at the moment, I'm sending software generated steps out thru the 5i20, but hardware generated steps would be better - I'm running into the speed and jitter limits of software stepping. (Of course, there is some driver writing to do first.) Regards, John ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
