Question about custom BOB for a 7i92
In general you cannot do that on Ethernet connected devices.I have a different machine that could benefit from being able to read an input pin and less importantly write an output pin as fast as possible running a 7i96. Would this actually be useful? I'd assume this has to exist in a faster thread than the servo, like a base thread?
What do these inputs or outputs do? maybe there is some,
firmware module that can do the faster I/O manipulation
Please Log in or Create an account to join the conversation.
In general PTCs are too slow to protect 24V driversAnother question for you PCW, if you're inclined to oblige....
The line driver I'm using for general outputs has a 400ma or so safe limit but no built in current protection. I'd be inclined to use PTCs or something but I can't find anything practical for ~30v @ 400ma......any suggestions?
Please Log in or Create an account to join the conversation.
drive.google.com/file/d/1axmgOS7w0YXyVlB...81I/view?usp=sharing
What do these inputs or outputs do? maybe there is some,
firmware module that can do the faster I/O manipulation
The video kind of explains it best I suppose. In this case the input comes from a contrast sensor. That resets the encoder position and sets pins on a custom hal component that performs a modulo operation. When the encoder position is >= the component's position setting it triggers and output to the camera, then allows the encoder to be reset again on the next input
I did this test just to see how accurate the whole thing is:
drive.google.com/file/d/14sGXzeZkgIF1WY5.../view?usp=share_link
That's a camera and it's strobe pointed at a 2" OD roller. It's being triggered from the same contrast sensor and encoder. By the end the roller is spinning over 2k rpms. There's a scenario where it uses an encoder index as the input instead of the contrast sensor.
The biggest bottleneck is obviously the software hal component and in practice it doesn't matter that much as long as all delays are consistent. If it were practical the whole thing would run as a FPGA firmware module rather than passing back and forth into hal. Still the faster I can read that input, run the component and trigger the output the better.
Please Log in or Create an account to join the conversation.
(and be accurate to 1 count)
Please Log in or Create an account to join the conversation.
They are in a zip file in this zip file:I don't suppose the hm2 sources are still available?
www.mesanet.com/software/parallel/7i92.zip
Please Log in or Create an account to join the conversation.
I figured that, unfortunately VHDL is about as Chinese as C or anything else to me.It sounds like that could be done with an extension of the encoder module
(and be accurate to 1 count)
If at some point in the future I knew someone who could modify the encoder module. Besides the logic, for a card like the 7i96 it would need to be able to address an extra input and output from within the module right? Would that be possible with a 7i96? I'm not sure if the IO is muxed or anything on that card.
Please Log in or Create an account to join the conversation.
If this is done at high speeds could a variable delay be sufficient?
(a variable delay with 10 ns resolution can be done with the oneshot module)
Please Log in or Create an account to join the conversation.
I wasn't able to do much with SPI on the first rev because of the missing component and that PCB mistake. One question I have is if the 7i92 IO is strong enough to drive the SCK for 5 devices on board with no buffer or anything? I dropped the external SPI port idea, it was getting a bit out of hand.
I have the 4 ADCs that only output so they don't use MOSI, and I added a small 8bit MCU as the stepper drives I'll be using need configuration over UART, that is connected to the 7i92's BSPI instance and is the only thing on MOSI. I think my friend has the gist of the bspi thing and configuring the MCU's EEPROM space will become hal parameters as part of this thing's component.
This is the pinout for hopefully what is the final firmware.
Attachments:
Please Log in or Create an account to join the conversation.
I'm sure a variable delay would not be an issue, I'd think overall hardware delays would be greater than anything in the FPGA module. Delays themselves aren't really a major issue anyway as long as things happen reasonably fast which even the current setup seems fast enough , the biggest thing is the consistency of the overall cycle. If it took 300ns to do the whole thing the first time, doing it faster the 2nd time would actually be worse.If this is done at high speeds could a variable delay be sufficient?
Please Log in or Create an account to join the conversation.
accomplish your task? If so this is already supported in hardware
Please Log in or Create an account to join the conversation.