1. Forum
  3. Search

Advanced Search

Search Results (Searched for: )

  • SOLD
  • SOLD
Today 12:47 - Today 12:49
Replied by SOLD on topic 7i92M + 7i76 add PWM+PktUART

7i92M + 7i76 add PWM+PktUART

Category: Driver Boards

Hello PCW,
I would like to ask for guidance regarding a firmware issue with a Mesa 7i92 + 7i76 system, and clarify the exact sequence of events.
LinuxCNC reported the following warning:
hm2/hm2_7i92.0: Warning: sserial remote device 7i76 channel 0 has old firmware that should be updated
Based on this warning, I attempted to update the Smart-Serial firmware.
At that time, I assumed that 7I76U.BIN could be used as a compatible replacement and used it to update the 7i76. This was a deliberate decision made in response to the hm2 warning, not an accidental flash.
After this, the system no longer behaves as expected.
Current status:
7i92 Ethernet communication works normally.
The Smart-Serial port responds and reports SSLBP version, channel count, and baud rate.
I reflashed with 7i92_7i76x1D.bit, followed by a full power cycle.
The W3 jumper on the 7i76 has been changed as recommended.
Attempting to rewrite 7I76R14.BIN via mesaflash produces no errors, however there is no explicit indication that a firmware rewrite actually occurred, and the observable behavior of the board does not change.

Is there any supported recovery method for a 7i76 in this condition, assuming access to a working Smart-Serial master (7i92)?
cnc@cnc:~/Desktop/UP FW7i77/sserial/utils/linuxcnc$ cd "/home/cnc/Desktop/UP FW7i77/sserial/utils/linuxcnc"
halrun -f update7i76u-eth.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
hm2_eth: loading Mesa AnyIO HostMot2 ethernet driver version 0.2
hm2_eth: 10.10.10.10: INFO: Hardware address (MAC): 00:60:1b:13:05:8a
hm2_eth: discovered 7I92
hm2/hm2_7i92.0: Low Level init 0.15
hm2/hm2_7i92.0: Smart Serial Firmware Version 43
hm2/hm2_7i92.0: num_channels = 4
hm2/hm2_7i92.0: Chan 0 baudrate = 2500000
hm2/hm2_7i92.0: Chan 0. Baudrate set to 115200
hm2/hm2_7i92.0: Chan 1 baudrate = 2500000
hm2/hm2_7i92.0: Chan 1. Baudrate set to 115200
hm2/hm2_7i92.0: Chan 2 baudrate = 2500000
hm2/hm2_7i92.0: Chan 2. Baudrate set to 115200
hm2/hm2_7i92.0: Chan 3 baudrate = 2500000
hm2/hm2_7i92.0: Chan 3. Baudrate set to 115200
Setup mode
found a 7I76
Setup mode
Looking for 8i20s, crc_addr = 192
found a     
Setup mode
Looking for 8i20s, crc_addr = 242
found a     
Setup mode
Looking for 8i20s, crc_addr = 292
found a     
hm2/hm2_7i92.0: 34 I/O Pins used:
hm2/hm2_7i92.0:     IO Pin 000 (P2-01): StepGen #0, pin Direction (Output)
hm2/hm2_7i92.0:     IO Pin 001 (P2-14): StepGen #0, pin Step (Output)
hm2/hm2_7i92.0:     IO Pin 002 (P2-02): StepGen #1, pin Direction (Output)
hm2/hm2_7i92.0:     IO Pin 003 (P2-15): StepGen #1, pin Step (Output)
hm2/hm2_7i92.0:     IO Pin 004 (P2-03): StepGen #2, pin Direction (Output)
hm2/hm2_7i92.0:     IO Pin 005 (P2-16): StepGen #2, pin Step (Output)
hm2/hm2_7i92.0:     IO Pin 006 (P2-04): StepGen #3, pin Direction (Output)
hm2/hm2_7i92.0:     IO Pin 007 (P2-17): StepGen #3, pin Step (Output)
hm2/hm2_7i92.0:     IO Pin 008 (P2-05): StepGen #4, pin Direction (Output)
hm2/hm2_7i92.0:     IO Pin 009 (P2-06): StepGen #4, pin Step (Output)
hm2/hm2_7i92.0:     IO Pin 010 (P2-07): Smart Serial Interface #0, pin tx0 (Output)
hm2/hm2_7i92.0:     IO Pin 011 (P2-08): Smart Serial Interface #0, pin rx0 (Input)
hm2/hm2_7i92.0:     IO Pin 012 (P2-09): Smart Serial Interface #0, pin tx1 (Output)
hm2/hm2_7i92.0:     IO Pin 013 (P2-10): Smart Serial Interface #0, pin rx1 (Input)
hm2/hm2_7i92.0:     IO Pin 014 (P2-11): Encoder #0, pin Index (Input)
hm2/hm2_7i92.0:     IO Pin 015 (P2-12): Encoder #0, pin B (Input)
hm2/hm2_7i92.0:     IO Pin 016 (P2-13): Encoder #0, pin A (Input)
hm2/hm2_7i92.0:     IO Pin 017 (P1-01): StepGen #5, pin Direction (Output)
hm2/hm2_7i92.0:     IO Pin 018 (P1-14): StepGen #5, pin Step (Output)
hm2/hm2_7i92.0:     IO Pin 019 (P1-02): StepGen #6, pin Direction (Output)
hm2/hm2_7i92.0:     IO Pin 020 (P1-15): StepGen #6, pin Step (Output)
hm2/hm2_7i92.0:     IO Pin 021 (P1-03): StepGen #7, pin Direction (Output)
hm2/hm2_7i92.0:     IO Pin 022 (P1-16): StepGen #7, pin Step (Output)
hm2/hm2_7i92.0:     IO Pin 023 (P1-04): PWMGen #0, pin Out1 (Dir or Down) (Output)
hm2/hm2_7i92.0:     IO Pin 024 (P1-17): PWMGen #0, pin Out0 (PWM or Up) (Output)
hm2/hm2_7i92.0:     IO Pin 025 (P1-05): PWMGen #1, pin Out1 (Dir or Down) (Output)
hm2/hm2_7i92.0:     IO Pin 026 (P1-06): PWMGen #1, pin Out0 (PWM or Up) (Output)
hm2/hm2_7i92.0:     IO Pin 027 (P1-07): Smart Serial Interface #0, pin tx2 (Output)
hm2/hm2_7i92.0:     IO Pin 028 (P1-08): Smart Serial Interface #0, pin rx2 (Input)
hm2/hm2_7i92.0:     IO Pin 029 (P1-09): Smart Serial Interface #0, pin tx3 (Output)
hm2/hm2_7i92.0:     IO Pin 030 (P1-10): Smart Serial Interface #0, pin rx3 (Input)
hm2/hm2_7i92.0:     IO Pin 031 (P1-11): Encoder #1, pin Index (Input)
hm2/hm2_7i92.0:     IO Pin 032 (P1-12): Encoder #1, pin B (Input)
hm2/hm2_7i92.0:     IO Pin 033 (P1-13): Encoder #1, pin A (Input)
hm2/hm2_7i92.0: registered
flash command
Firmware size 0x953c
setup start: data_reg readback = 0
hm2/hm2_7i92.0: Write Size = 100, Erase Size = 800
hm2/hm2_7i92.0: Skipped Block 1
hm2/hm2_7i92.0: Skipped Block 2
hm2/hm2_7i92.0: Skipped Block 3
hm2/hm2_7i92.0: Skipped Block 4
hm2/hm2_7i92.0: Skipped Block 5
hm2/hm2_7i92.0: Skipped Block 6
hm2/hm2_7i92.0: Skipped Block 7
hm2/hm2_7i92.0: Erased block 8
hm2/hm2_7i92.0: Wrote block 8
hm2/hm2_7i92.0: Skipped Block 9
hm2/hm2_7i92.0: Erased block 10
hm2/hm2_7i92.0: Wrote block 10
hm2/hm2_7i92.0: Erased block 11
hm2/hm2_7i92.0: Wrote block 11
hm2/hm2_7i92.0: Erased block 12
hm2/hm2_7i92.0: Wrote block 12
hm2/hm2_7i92.0: Erased block 13
hm2/hm2_7i92.0: Wrote block 13
hm2/hm2_7i92.0: Erased block 14
hm2/hm2_7i92.0: Wrote block 14
hm2/hm2_7i92.0: Erased block 15
hm2/hm2_7i92.0: Wrote block 15
Error flag set after CMD Clear 00000001
hm2/hm2_7i92.0: Error in sslbp_write_byte, trying to abort
Error flag set after CMD Clear 00000001
hm2/hm2_7i92.0: Error in sslbp_read_cookie, trying to abort
hm2/hm2_7i92.0: Synch failed during block erase: aborting
Error flag set after CMD Clear 00000001
Firmware Flash Failed
setsserial: rtapi_app_main: Operation not permitted (-1)
setsserial: not loaded
<commandline>:0: exit value: 255
<commandline>:0: rmmod failed, returned -1
hm2_eth: in hm2_eth_reset
hm2_eth: HostMot2 ethernet driver unloaded
hm2: unloading
<commandline>:0: unloadrt failed
Note: Using POSIX realtime
cnc@cnc:~/Desktop/UP FW7i77/sserial/utils/linuxcnc$
  • unknown
  • unknown
Today 12:46
Replied by unknown on topic Mini PC for LinuxCNC/CPU Realtime Performance

Mini PC for LinuxCNC/CPU Realtime Performance

Category: Computers and Hardware

With Mesa cards latency isn't such as issue as with using the Parallel port. I think the rule of thumb is under 100000ns is good for a mesa card, for about 99% of uses, cos I know someone will have an example that breaks the rule of thumb. Or my numbers may be wrong.
Unlike one forum I can think of we dont have p*$##&€ contests. ;)
If it works and does the job reliably that's the goal.
  • tommylight
  • tommylight's Avatar
Today 12:33
Replied by tommylight on topic Mini PC for LinuxCNC/CPU Realtime Performance

Mini PC for LinuxCNC/CPU Realtime Performance

Category: Computers and Hardware

@NVE,
can you do the latency test with no base period and with added --show at the end as there are excursions on both periods on your screenshot, and base period is not used for Mesa boards.
Thank you.
  • tommylight
  • tommylight's Avatar
Today 12:31
Replied by tommylight on topic Which Mesa Card Should I Buy?

Which Mesa Card Should I Buy?

Category: Driver Boards

Mesa 7i96S is the best choice for Plasma.
I would really not advise using 7i92 for plasma unless you are very good at wiring and grounding and shielding.
  • masawee
  • masawee
Today 12:23
Replied by masawee on topic Which Mesa Card Should I Buy?

Which Mesa Card Should I Buy?

Category: Driver Boards

im newbie, and think need update my cnc machine whit mesa card, but true not understand and know what card need order, and totally not understand how flash firmware to card, if need flash. my old cnc machine has now only cheap paraller port BOB but problem is no have input pins, i want add my machine MPG pendant help lot whit work. what card i need order i not undrstand.
my cnc have 4 stepper motor dual Y axis, X,and Z,
input have now only XYZ home inductive sensor,
probe.

need add MPG hand wheel and switch,
one more stepper motor whit limit SW (4th axle to lathe on table addon)
cool flood output relay,
air cool relay,
maybe future some addons.
What card need buy ???
and were have download all speak lot this different bit files.

second project is buy cheap 7i92 mesa clone board aliexpress and need make plasma table.
how this add or flash bit file and were can download good bit file,
can 92 board use palsma X,Y,Z axis, THC what need doing ????
this need maybe 3 motors 6pin out,
THC i not know what need,
home SW 3 input,
output to plasma ?
what more need be?
  • giaviv
  • giaviv
Today 11:57
Replied by giaviv on topic Mini PC for LinuxCNC/CPU Realtime Performance

Mini PC for LinuxCNC/CPU Realtime Performance

Category: Computers and Hardware

this is great, thanks for the info! what do these results indicate regarding how good this setup is for the linuxcnc application? im new to linuxcnc so the raw data doesn't mean much to me...
  • grandixximo
  • grandixximo's Avatar
Today 11:45
Replied by grandixximo on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

@endian I discussed this with YangYang who attends the EtherCAT consortium meetings. AitalMAC is part of the consortium and we design I/O for EtherCAT, so we're not guessing here.
The standard already solves this problem. You don't need pos(t+1).
The 1 cycle delay is real, but it's identical for all axes. With Distributed Clocks everything executes on the same SYNC edge, synchronized to ~100ns. Every axis is "late" by the same amount, so the path shape is correct. Calculate it last week, execute it this week, the part is the same.
The CiA 402 standard provides feedforward objects exactly for this: 0x60B1 (velocity offset) and 0x60B2 (torque offset). The master can send position plus velocity feedforward so the drive can anticipate acceleration. This is the standard's solution, it just needs to be mapped in lcec.
Also, good drives interpolate internally. The servo loop runs faster than the bus cycle (Maxon runs 0.4ms internal vs 1ms bus). The drive doesn't jump between positions, it interpolates. That's what 0x60C2 configures.
If you're seeing ferror correlate with velocity in halscope, that's likely a display artifact. The ferror compares "commanded from 1 cycle ago" with "actual now", so it shows an offset proportional to velocity. It's not a real machining error.
What does your actual part surface look like? Any real deviation you can measure?
  • unknown
  • unknown
Today 11:40
Replied by unknown on topic The fear of being homeless is over, found new digs.

The fear of being homeless is over, found new digs.

Category: Off Topic and Test Posts

Yeah I know, I dunno what's happened to Australia, it's shameful and I'm embarrassed.
  • my1987toyota
  • my1987toyota's Avatar
Today 10:26 - Today 10:34
Replied by my1987toyota on topic The fear of being homeless is over, found new digs.

The fear of being homeless is over, found new digs.

Category: Off Topic and Test Posts

Hang in there unknown it's not just the USA loosing it's sanity. The world is becoming Idiocracy incarnate.
  • meister
  • meister
Today 09:44
Replied by meister on topic Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Category: Driver Boards

1. I am put off by the fact that the firmware is not open source.
2. The HAL driver seems a bit over-engineered to me, a user component is perfectly adequate for MPG/HMI. it does not need to be a real-time component !
3. Another problem with USB is that it is not really error tolerant. After a minor error, the entire connection usually has to be reinitialised, which causes long timeouts.
4. Serial/USB is also not suitable for real-time tasks in the servo thread, i.e. not only as described for direct step/dir tasks in the base thread.
This is not a myth but has already been tested by many.

My assessment is that a serial driver as a real-time component offers no advantage whatsoever and only slows down the real-time threads.
  • endian
  • endian's Avatar
Today 09:43
Replied by endian on topic LinuxCNC S-Curve Accelerations

LinuxCNC S-Curve Accelerations

Category: General LinuxCNC Questions

Sounds all sensible to me but I really don't feel competent to comment on the proposed path.
I certainly like the structured approach of your initiative, that is something that has been sorely lacking in other attempts.
I think/hope that Rob will be able to give an educated opinion on it and shape it into a concrete roadmap.

Note that Mitsubishi SSCNET requires a servo cycle <= 222us
forum.linuxcnc.org/9-installing-linuxcnc...cnet?start=70#256576
 
defenetly is great to have something faster then 1ms .. ethercat can run at 50us with 16axis but this complex calculations are far slower for now 

I think 250us is very pretty goal (common industrial standard) at any hardware and then reduce it based at used hardware 


Note than many ethercat drives are also limited to 1khz in position mode. lichuan is, stepperonline/jss i think is and Im pretty sure the delta b3 is. My omrons I think are restricted to 2khz in csp mode.

For 4khz or 8khz usually you are restricted to other modes. At least in the drives I have. There definitely are (much) faster ones, but they are more specialised gear vs generic milling cnc applications.

Point being, 250us sounds great, but I don't know it needs to be any sort of priority cause only few people could use it. But then maybe those few people are important (like the people I know wanting to nanometer scale optical things and MUST have the higher "loop" speed so can't entertain linuxcnc right now)
 
You are right, I agree with you 100%, main goal is get lcnc with curves at 1khz ... Timig is very wide and difficult topic but faster code means more play to some latency or timig issues of something, stability, rigidity etc...

I think it is reachable timing .. faster tick means better final result of movement and better regulation feedback with velocity or current control.. 

Then we can say isolated cpu to sleep if it will runs at longer timing then 250us .. finally we can use more masters at other network interface to run it with different timing if it is needed and then let cpu to sleep

I think Luca's goal are very very well definied .. from my point of view there is missing just pos(t+1) or pos(t-1) for position commands to any drivers which is not using the velocity setpoint(its cosmetic to not see the ferror during movement with position setpoint)

We can runs 16khz with beckhoff but there is latency restictions... for now... I am running 0.5khz with profibus equidistant and it works well but with trapeziodal its was pain.. now with scurve its smooth like butter... lower timing than 1khz are for gentelmen which they know what they are doing.. its advanced I think
 


Gentelmen, I am sorry for talking about editing and adding the positionCmd(t+1) or positionCmd(t-1) to active creating planner but there is a problem of unsynchronized movement or synchronized(t+-x) motion ... it is common issue of any outsourced position control stuff

if somebody has stuff for example running at ethercat with CSP, he/she will be still in lag for cycle or two cycles(if he/she will not has reference cycle negative) behind stuff at same control master for example CSV which will have PID- with FF1 set to 1.0 ... feedforward compensation will not be present and lagging axis will create(during higher speed motion) unsynchronization and it could influence final shape during some 3d pathing or finishing...  with higher speed it will create higher lag (I am talking about ethercat because I can test it myself at my HW)

this is just my ideas, please let me know your point of view ... 

thanks
  • unknown
  • unknown
Today 09:37
Replied by unknown on topic Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Category: Driver Boards

You can build firmware to enumerate as a HID class device, Linuxcnc already has a generic driver, config for the USB firmware side can be a little tricky. The original Microchip dev kits were a nightmare to get going.
  • unknown
  • unknown
Today 09:33
Replied by unknown on topic Mini PC for LinuxCNC/CPU Realtime Performance

Mini PC for LinuxCNC/CPU Realtime Performance

Category: Computers and Hardware

Not a PC platform, but the RPi5 is more than capable running with a Mesa card, Ethernet or SPi......... Not something Tommy would recommend. I didn't for a while.....but things change.
  • NWE
  • NWE
Today 09:10
Replied by NWE on topic Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Category: Driver Boards

Here is what is tripping me up: the Arduino UNO uses hardware serial converter between the USB and the mcu. That is much more limited than the Arduinos with native USB directly to the mcu without the serial converter. I understand the UNO is your "demo" config? Does your dedicated hardware do USB direct to the mcu? Does it use some version of the CDC class?
  • bobwolf
  • bobwolf
Today 06:05
Replied by bobwolf on topic Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Solving the USB Latency Dogma for HMI/MPG: Technical Feedback Request

Category: Driver Boards

I totally get your point about USB and its limitations in RT applications. That's exactly why I started this project.

To answer your question: No, this is not just a 'simple serial project'.

Unlike the common Arduino-Serial implementations, io_decoder uses a dedicated HAL driver (written in C) that manages communication at a deeper level. I focused heavily on optimizing the packet structure and the polling cycle to minimize jitter and ensure that the HMI response feels 'instant' to the operator.

While motion control (step/dir) should definitely stay on Mesa/EtherCAT, io_decoder is designed to provide a professional-grade, low-latency interface for complex HMI panels where standard USB HID or generic serial bridges fail to deliver the required responsiveness.

Furthermore, io_decoder isn't just a coding experiment; it's a ready-to-use solution.

Along with the driver and firmware, I have designed dedicated hardware boards specifically for this project. The goal is to provide a plug-and-play experience: you take the board, flash the firmware, and you have an interface ready for your machine.

It's about bridging the gap between a 'DIY hack' and a reliable, documented interface.

I’d love for you to check the source code of the HAL driver on my GitHub—I think you’ll find it’s a bit different from the 'well-trodden paths' you mentioned!
Displaying 1 - 15 out of 281842 results.
  1. Forum
  3. Search
Time to create page: 1.764 seconds
Powered by Kunena Forum