Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Bug]: Long G-code replies can crash WiFi boards in standalone mode #1073

Open
1 of 25 tasks
chrishamm opened this issue Jan 28, 2025 · 5 comments
Open
1 of 25 tasks

[Bug]: Long G-code replies can crash WiFi boards in standalone mode #1073

chrishamm opened this issue Jan 28, 2025 · 5 comments
Assignees
@dc42 @rechrtb
Labels
bug Bug that has been reproduced
Milestone
3.6.0

Comments

@chrishamm
Copy link
Collaborator

Duet Forum Discussion Thread

https://forum.duet3d.com/topic/37322/3-6-0-beta-3-dwc-connection-issues-duet2-duex5

Which Duet products are you using?

  • Duet2-Wifi
  • Duet2-Ethernet
  • Duet Expansion Breakout Board
  • Duex2
  • Duex5
  • Duet2-Maestro
  • Maestro Dual Driver Expansion
  • Duet3-6HC
  • Duet3-3HC
  • Duet3-1XD
  • Duet3-1LC
  • Duet3-Tool Distribution Board
  • Duet3-Mini5+
  • Duet3-Mini2+
  • Raspberry Pi or other SBC
  • SmartEffector
  • Magnetic Filament Sensor
  • Laser Filament Sensor
  • PT100 Daughterboard
  • Thermocouple Daughterboard
  • PanelDue
  • Other
  • None

Firmware Version

3.6.0-beta.3

Duet Web Control Version

3.6.0-beta.3

Are you using a Single Board Computer (RaspberryPi) with your Duet?

  • Yes I use a SBC.
  • No I do not use a SBC.

Please upload the results of sending M122 in the gcode console.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-beta.3 (2025-01-16 19:09:12) running on Duet WiFi 1.02 or later + DueX5v0.11
Board ID: 08DJM-9178L-L4MSJ-6J1FL-3S86J-TB2LN
Used output buffers: 3 of 26 (26 max)
=== RTOS ===
Static ram: 23520
Dynamic ram: 70940 of which 12 recycled
Never used RAM 16980, free system stack 108 words
Tasks: LASER(5,nWait 6,0.0%,214) NETWORK(1,ready,13.9%,181) HEAT(3,nWait 5,0.1%,283) Move(4,nWait 5,0.0%,266) DUEX(5,nWait 5,0.0%,23) MAIN(1,running,85.4%,689) IDLE(0,ready,0.6%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 05:21:48 ago, cause: power up
Last software reset at 2025-01-22 17:09, reason: User, Gcodes spinning, available RAM 16628, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x04
MCU temperature: min 31.0, current 31.3, max 31.7
Supply voltage: min 23.8, current 23.9, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/8, heap memory allocated/used/recyclable 2048/860/700, gc cycles 898
Events: 1 queued, 1 completed
Date/time: 2025-01-23 15:28:16
Slowest loop: 9.76ms; fastest: 0.21ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 2.2ms, write time 0.8ms, max retries 0
=== Move ===
Segments created 356, maxWait 0ms, bed comp in use: mesh, height map offset -0.009, hiccups added 0/0 (0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 99920.00/99920/0.00 35280.00/35280/0.00 157593.00/157593/-1.00
no step interrupt scheduled
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min n/a
Driver 2: standstill, SG min n/a
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5: standstill, SG min n/a
Driver 6: standstill, SG min n/a
Driver 7: standstill, SG min n/a
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10: 
Driver 11: 
=== DDARing 0 ===
Scheduled moves 153592, completed 153592, LaErrors 0, Underruns [0, 0, 0]
Segments left 0
Code queue is empty
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.2
=== GCodes ===
Movement locks held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
=== Filament sensors ===
check 25695622 clear 41201439
Extruder 0: pos 2403.98, errs: frame 1 parity 0 ovrun 34 pol 0 ovdue 0
=== DueX ===
Read count 0, 0.00 reads/min
=== Network ===
Slowest loop: 22.18ms; fastest: 0.09ms
Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 2 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.2.1
MAC address bc:dd:c2:31:9a:40
Module reset reason: Turned on by main processor, Vcc 3.45, flash size 4194304, free heap 41804
WiFi IP address 10.42.0.2
Signal strength -15dBm, channel 11, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 5 3 3 3 0 0 0 0

Please upload the content of your config.g file.

Config.g

Please upload the content of any other releveant macro files.



Details specific to your printer.


No response


Links to additional info.


No response


What happened?


Three consecutive M122 calls (M122 M122 M122) make create issues with the SPI communication between RepRapFirmware and DuetWiFiServer:


{ GET /rr_gcode HTTP/1.0 }, parameters { gcode=m122 }Bad recv status sizeError: failed to retrieve WiFi status message: another SPI transfer is pendingBad recv status sizeBad recv status sizeError: failed to retrieve WiFi status message: another SPI transfer is pendingBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeError: failed to retrieve WiFi status message: SPI timeoutBad recv status sizeReleased gcodeReply, free buffers=26Error: failed to retrieve WiFi status message: SPI timeoutBad recv status size


      		
    

      
  





        



            

              
            

        

      


      
    








      

    



      

  
            

    

      
    

    


      

          @chrishamm
chrishamm




          added
  the 

  bug

  Bug that has been reproduced
 label


      Jan 28, 2025

    

  



    


    

    

      
    

    


      

          @chrishamm
chrishamm




          added this to the   3.6.0 milestone


      Jan 28, 2025

    

  



    

    

      
    

    


      

          @T3P3
T3P3




          assigned     dc42 and     rechrtb   and unassigned     x0rtrunks

      Jan 28, 2025

    

  








      

  
      



  

  @timschneider





  


    

      

  

    

        
    
    

  


      
          
  
      
            Copy link

  

      
    

  


  

      



      

  


  

    

  





      


        


  
    

      
          
In addtion to the description above, the Duet is equipt with an PT100 daugther board.


and today I was able to reproduce the WIFI Module stuck.


HTTP req, command words { GET /rr_gcode HTTP/1.0 }, parameters { gcode=M122 }<\n>
Sending JSON reply, length 12<\n>
ResponseTimeout, pending=1<\n>
ResponseBusy<\n>
Bad recv status size<\n>
WiFi: ˆ�n�P<24>|�!�-�1Ë�5‹Ðšö›X�%�ú~�)Q*!Ë�è "X*�<7>�í�×�v�'�áêI*�1�T�,�,�)�)DÐ�b9�)�5~�/�<9>�øn�z�A[�a�øºv�<5>¬�<9>�H~�1�hqh�5�5~�9<1>�êt�l�-�§�X�1�¨Y+�5�%�ûþ�<5>1�<11>�<9>�ˆò�A,�<9>�8øºö�<5>1�R�d�!y(�!�‡�z�A‹�ëy¨�%�!y¨�1�R·�v�-<\n>
ESP reported status change<\n>
ResponseBusy<\n>
WiFi: �)�)DP‹�­@íy*�-�<9>�øn�z�Aì )ií�§�P�m�N8r�fP�m�Nøphy_version: 1163.0, 665d56c, Jun 24 2020, 10:00:08, RTOS new<\n>
ESP reported status change<\n>
ResponseBusy<\n>
Error: failed to retrieve WiFi status message: another SPI transfer is pending<\n>
Error: failed to retrieve WiFi status message: another SPI transfer is pending<\n>
ResponseBusy<\n>
Bad recv status size<\n>
ResponseBusy<\n>
Bad recv status size<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
ESP reported status change<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrieve WiFi status message: SPI timeout<\n>
ResponseTimeout, pending=1<\n>
Bad recv status size<\n>
ESP reported status change<\n>
ResponseTimeout, pending=1<\n>
Error: failed to retrie



it took me some time to get it trigger this SPI conflict - i do often see


Ran out of output buffers at ../src/Networking/HttpResponder.cpp(1109)<\n>



but rarly the SPI timeout - the Problem with the SPI timeout is that the printer won't recover, you need to power cycle the printer.


Output of M122 after Power-Cycle


M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-beta.3 (2025-01-16 19:09:12) running on Duet WiFi 1.02 or later + DueX5v0.11
Board ID: 08DJM-9178L-L4MSJ-6J1FL-3S86J-TB2LN
Used output buffers: 2 of 26 (19 max)
=== RTOS ===
Static ram: 23520
Dynamic ram: 68268 of which 12 recycled
Never used RAM 28196, free system stack 184 words
Tasks: NETWORK(1,ready,7.8%,217) HEAT(3,nWait 5,0.1%,283) Move(4,nWait 5,0.0%,361) DUEX(5,nWait 5,0.0%,23) MAIN(1,running,90.8%,726) IDLE(0,ready,1.4%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:01:00 ago, cause: power up
Last software reset at 2025-01-27 15:25, reason: User, Gcodes spinning, available RAM 28108, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 22.8, current 26.7, max 26.9
Supply voltage: min 22.9, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/7, heap memory allocated/used/recyclable 2048/524/388, gc cycles 3
Events: 0 queued, 0 completed
Date/time: 2025-01-29 11:48:43
Slowest loop: 7.64ms; fastest: 0.21ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 5.5ms, write time 4.5ms, max retries 0
=== Move ===
Segments created 0, maxWait 0ms, bed comp in use: none, height map offset 0.000, hiccups added 0/0 (0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00
no step interrupt scheduled
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min n/a
Driver 2: standstill, SG min n/a
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5: standstill, SG min n/a
Driver 6: standstill, SG min n/a
Driver 7: standstill, SG min n/a
Driver 8: standstill, SG min n/a
Driver 9: standstill, SG min n/a
Driver 10: 
Driver 11: 
=== DDARing 0 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
Segments left 0
Code queue is empty
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
=== Filament sensors ===
check 0 clear 224046
Extruder 0: pos 2160.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
=== DueX ===
Read count 1, 1.00 reads/min
=== Network ===
Slowest loop: 24.29ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.2.1
MAC address bc:dd:c2:31:9a:40
Module reset reason: Turned on by main processor, Vcc 3.45, flash size 4194304, free heap 42668
WiFi IP address 10.42.0.2
Signal strength -26dBm, channel 11, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0


      		
    

  





        


            

            

              
            

        

      


      

            
  

    
  
    
    

  

  



    












      

  
      



  

  @rechrtb





  


    

      

  

    

        
    
    

  


      
          
  
      
            Copy link

  

      
    

  


  

      

  
    Contributor


      

  


  

    

      

      
            rechrtb
  

      

      

      commented


        Jan 29, 2025


      
    


  





      


        


  
    

      
          
Ok, will take a look.

      		
    

  





        


            

            

              
            

        

      


      

            
  

    
  
    
    

  

  



    












      

  
      



  

  @T3P3





  


    

      

  

    

        
    
    

  


      
          
  
      
            Copy link

  

      
    

  


  

      

  
    Contributor


      

  


  

    

      

      
            T3P3
  

      

      

      commented


        Feb 3, 2025


      
    


  





      


        


  
    

      
          
Sending M122 twice in an single line reproduced the disconnection in 3.6beta3 on a duet 2 wifi for me

      		
    

  





        


            

            

              
            

        

      


      

            
  

    
  
    
    

  

  



    












      

  
          


  
    
  
  

    
  chrishamm 

      added a commit
      that referenced
      this issue

    
      Feb 4, 2025
    
    

      


  

    

      


  

      
        @chrishamm
  





      

        
          Fix for too long G-code replies (#1073)
        

          
            
          

      


      

          

    
    
    

  

      


      

      


      
      

        
          a3498d3
        
      

    

  

    

      
Added extra parameter to OutputBuffer::Allocate to specify if the buffer
to be allocated may be taken from the output buffer reserve. This is
always true except if appending to an existing output buffer chain or
when the request may be repeated without downsides.
Also reduced the number of reserved output buffers to 2 on Duet 2 series

    




    

  









      

  
      



  

  @chrishamm





  


    

      

  

    

        
    
    

  


      
          
  
      
            Copy link

  

      
    

  


  

      

  
    Collaborator


      

  Author


  


  

    

  





      


        


  
    

      
          
I have implemented a fix for a bug which could lead to the web server hanging up from multiple M122 codes in a single command. The cuplrit was the fact that M122 kept appending to the same G-code reply and eventually the last available output buffer item was taken, so the network responder could never allocate one for outBuf. As a result, the web server failed to write an HTTP header and all connected sessions would time out. See the linked commit for further details.


I have not yet checked if this has an impact on the reported SPI transfer errors but it is quite possible.

      		
    

  





        


            

            

              
            

        

      


      

            
  

    
  
    
    

  

  



    












      

  
      



  

  @chrishamm





  


    

      

  

    

        
    
    

  


      
          
  
      
            Copy link

  

      
    

  


  

      

  
    Collaborator


      

  Author


  


  

    

  





      


        


  
    

      
          
@timschneider Here a new Duet 2 build. Please let me know if that resolves your connectivity problems.


Duet2CombinedFirmware.zip

      		
    

  





        


            

            

              
            

        

      


      

            
  

    
  
    
    

  

  



    












      

  
          


  
    
  
  

    
  dc42 

      pushed a commit
      that referenced
      this issue

    
      Feb 5, 2025
    
    

      


  

    

      


  

      
        @chrishamm
      
        @dc42
  





      

        
          Fix for too long G-code replies (#1073)
        

          
            
          

      


      

          

    
    
    

  

      


      

      


      
      

        
          e122d04
        
      

    

  

    

      
Added extra parameter to OutputBuffer::Allocate to specify if the buffer
to be allocated may be taken from the output buffer reserve. This is
always true except if appending to an existing output buffer chain or
when the request may be repeated without downsides.
Also reduced the number of reserved output buffers to 2 on Duet 2 series

    




    

  













  
  

    

      

  





  




  
  

              

  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment


  



  






  
                  




    

  


      
  

    Assignees
  



        

      

        

  
      @dc42
  
    dc42
    

      

      

        

  
      @rechrtb
  
    rechrtb
    

      








      


  


  

    Labels
  



    

      

    bug

  Bug that has been reproduced








      

  

    

        

    Projects
  


        




    None yet




  



      


  

    
  

    Milestone
  


      
    
  
    3.6.0
  





    
      
          


  

    
      

        
    

    Development
  




          
    
No branches or pull requests







    
  




      

    

  
      

  

    

      6 participants
    

    

        
          @x0rtrunks 
        
          @T3P3 
        
          @timschneider 
        
          @dc42 
        
          @chrishamm 
        
          @rechrtb