Advanced Search

RobotMatic wrote:

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,

Hmmm, if it works, i am sure LinuxCNC can find it as parallel port, the driver in use being serial is strange if there is actually nothing serial on the board, but from experience most of those boards do show as serial and parallel or both, despite missing serial ports.
I would aim at missing "driver in use" when the error appears...

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)

Focus is a bit off but it's exactly the same as mine. If you disconnect at the elbow you will see what I mean about the tube going to the rotary joint being free to spin.
The way they are set up means you couldn't extent the Y quill for a special machining set up as the elbow would jamb on the rear of the Y slide.
Maybe you could shine a torch down the hole to see if there is anything else stopping the tube pulling out with the quill.
I haven't had a chance to figure out if there is an anti rotation slot and pin on the quill. You have to remove the one on the Z quill to remove that quill.
Cheers,
David

Just got my BRIX i7-7557 delivered and I pulled it apart to just look inside as the listing said 256gb SSD. Well it has 2 SSDs, one mounted to the board and the other mounted to the back cover like normal. Both of them Samsung with the small board mounted one being 500gb and the cover mounted o e being 1TB and it’s an 850 EVO which shocked me. I only paid $110 for this computer and wasn’t expecting this much coin in SSDs to be inside. 

what do you recommend, pull one and just use the board  mounted SSD ok keep them both? Seams kinda over kill to use such a nice SSD for just LinuxCNC QRplasmaC.
Thank you for any advice you can provide on setting this up for optimal performance.

Trial photo Kind regardsChris 

you mean if a analog value is above X = High, if below = LOW?

The hardest part of working with the parallel port is getting the latency down as you have 2 threads going and the fact the base thread is usually 25000 ns for decent stepper speed .
With a mesa setup you only need a servo thread running at 1ms. Getting the latency right is far less work, usually it's good right out of the box. You'll find you machine moves more smoothly, due to the stepper signals being generated by hardware.
It's all plus plus, mesa is well supported on the forum, Pete is an absolute gent, mesa products are rock solid and quite expandable via their Smart serial interface.
I know most people on the forum will recommend Mesa, but the thing is they are that good.

Glad to hear you're up & running.

Cheers
Rob

Brilliant!  I just had GMNOCCAPY up and running for hours without a glitch after making that change.  Believe you nailed it.

Thanks for the great tip.

Jeff

Thanks scotta , ini and hal attached.
I played around with the p i d settings today in the INI but it made no difference. Dip in voltage was still there. Also when I set the gain to 0.0025 which should be the correct value for 4000rpm. It doesn't scale right. I need to input 0.02 for it to work.