Advanced Search

No "serialized parallel" or "parallel serialized" no no noooooooo!
I really do not like labeling stuff at random like that, it is a parallel port interface running on a PCI-E bus, not the same thing and absolutely not something to be mixed at random.
The one with serial ports is an UART running on a PCI-E bus, nothing in common except the "serial" part.
-
Watching RoboMatic's pictures it just dawned on me, the normal PCI ports use one of the 16 IRQ's (FYI PC has 16 IRQ from 0-15) but this in the picture is 16 and still shows like a normal IRQ, so i wonder.... but the other one is IRQ32 and in a group of IOMMU so it has no memory address.
Also most probably lack of DMA access might be triggering the warning...
This needs more testing, whenever i get a chance, and whenever i get more PCI-E ones as i am out of those for now.

the point is that Linuxcnc does not find a parallel port, it finds a port that it can use but the kernel driver defines it as serial, it does not matter what is the capacity of the micro that uses the PCIE board, nor does it interest all the capabilities that you mention. Linuxcnc does not know how to solve the situation and gives us an alarm with a dual message, everything works perfectly, we are the ones who have to follow. I'm asking if you can somehow eliminate this situation of alarm or Dual message, I'm not trying to discuss technology, Nothing in the cpus works in Parallel, everything is serial, if you think differently perfect, I have no problem with that, but please don't deviate the reason why this thread was created in the forum. Thanks a lot.

By your definition of the PCIe being serial, no arguments there, it would be better described as a serialised parallel port. Generally any PCIe card would be described as a serialised device.
A more correct definition is a parallel/serial chip with a PCIe interface. Mesa sells PCIe motion control cards, would you call them serialised motion control cards ? What about GPUs, multilaned serialised devices ? Or look at the RPi 5 with the new RP interface chip, the GPIOs are on this chip which is connected via the PCIe bus, are they part of your serialised definition ?
Generally most people would look at the end point, not the bus of the computer. It's just easier to increase the speed of a serial bus compared to a parallel bus on a PCB. Trace length really comes into play, reflection, termination and many other things are more difficult routing wise with high speed parallel buses.

With regards to the chips used I think you would get a better understanding if you had a look at the data sheets. You'd be surprised the actual functions that these cards can perform. Some go further than just serial or parallel.

As PCW mentioned a change in the definition of the message would sort this out. If you feel strongly enough this should be changed, mention this on the Linuxcnc GitHub, as this is where changes to the code get done.

Looking for some guidance on best practice for Servo Enable for the 12A8 servo drives.  The original control has an AC transformer that sends 50V AC to a PCB that contains a rectifier bridge for DC voltage, has the connectors for the motors and tach signals, an interface for the -10/+10V control signals, as well as 3 relays.  One relay for the inhibit circuit for each drive and one to connect the DC drive voltage to the servo drives.  However, all three relays are driven by one 12V control signal.  I was hoping to reuse the existing power supply and pcb and plan to interface with it via the Mesa 7i97T.    From what I've read though, you cannot have two output signals connected to one physical pin, for example X Servo and Y Servo enable both driven by X servo enable circuit.  

Here are the options I'm considering:
1. Wire both enables from X and Y to the 12V relay, not sure if this would cause issues on the Mesa board if for some reason one servo was enabled and the other was not. Although, from reading the 7i97T manual, it seems like the enables are all switched in common?
2. Bypass the circuit board for enables and go straight to the drives with the enable circuit  (However, I would still need to enable the relay to connect drive power, so not sure which signal I could use for this.)  Perhaps I could make a new signal that would send 12V from the Mesa board if either of the X or Y drive enable commands are enabled, or route this to the estop switch and control it outside of the 7i97T.
3.  Any better ideas?
 

I attach 2 images of different boards Pcie.La board that has Kernel Driver parport_serial(Linuxcnc boots clean without the alarm in question). The board that has the Kernel Driver Serial (Triggers the Alarm in question). Both plates work perfectly.
I insist on the concept of a parallelized serial port. The PCEI architecture is serial and the expansion boards are responsible for parallelizing so that we can have an LPT port at the end. LinuxCNC should contemplate this situation to boot clean without the alarm. Because everything works perfectly.

You lucky b....
Leave the small one in, yank the big one out.
Nice that i do not have to explain more as the physically small is also capacity small.
Reason for it being, the small one seems to be M-SATA only, so it will not work on some normal mainboards, while the big one works on anything with a normal SATA connector. Or you can buy an external case for the big one at usually 7-15$ (insist on finding a USB-C or USB 3.0) and use it for whatever you like, even installing LinuxCNC on it and testing any PC you come near to, since Linux boots from anything and on anything (well almost, for me 99% of the time)