Question about custom BOB for a 7i92

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?

In general you cannot do that on Ethernet connected devices.

What do these inputs or outputs do? maybe there is some,
firmware module that can do the  faster I/O manipulation

blazini36 wrote:

Another 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?
 

In general PTCs are too slow to protect 24V drivers

PCW wrote:

What do these inputs or outputs do? maybe there is some,
firmware module that can do the  faster I/O manipulation

drive.google.com/file/d/1axmgOS7w0YXyVlB...81I/view?usp=sharing

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.

It sounds like that could be done with an extension of the encoder module
(and be accurate to 1 count)

PCW wrote:

It sounds like that could be done with an extension of the encoder module
(and be accurate to 1 count)
 

I figured that, unfortunately VHDL is about as Chinese as C or anything else to me.

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.

Nothing is muxed on the 7I96/7I96S

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)

The 2nd revision looks about ready but I figured I should post the drawing of the SPI decoder and input multiplexer to make sure I didn't get anything wrong.
 
 

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.
 
 

If this is done at high speeds could a variable delay be sufficient?

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.

What I was asking is could a variable time delay triggered by an input pin
accomplish your task? If so this is already supported in hardware