Using talking to my Ramps with Repetier-Server via Bluetooth

Ok I think I have gone off the rails and this is driving me mad.
(first of all first time caller but I brought the pro version late last year and I am still very happy with my purchase of such a great product)

I am setting up the electronics for my printers (the main one is outside in a large metal box and that has the Repeiter-Server installed on a Raspberry Pi. it talks to the main printer with USB so there are no issues there.

The second printer is inside and I want to control that with bluetooth on a Ramps 1.4 board this is the one I am having problems with.

I believe the Jy-mcu module is working because after configuring it to 115200 I can read text I am sending to it from the pi in a logic analyzer.
(I should note that I had to type in the /dev/rfcomm0 in the port on the printer settings when I do that the light on the BT module light go static telling me it is connected)

Originally I put the wires from the module from the BT module into D0 and D1 of Aux1. and I would see Repeiter-Server attempting to connect then it would have the broken link icon. when I reverse the connection I would see in the gcode window external reset and ram messages (I think this is from Repeiter-Server and not the device) after doing a search on the fourms, I read that the pins on the ramps needed to be remapped so we would need to connect to pin 17 and pin 18 on aux 4 (what I assume is D16 and D17) I am still getting the same result.

I wonder if it is something I have messed up in the firmware config file (I used both #define BLUETOOTH_SERIAL 2 (as well as -1) and I have changed "bluetoothSerial": 2 in the connection string area)

Any help would be great :)

Cheers
Stephen

Comments

  • Note: I should of proof read the subject line (was very early in the morning :P )

  • Well note sin configuration.h say:
    - On RAMPS we must remap Y_ENDSTOPS pins or Z_ENDSTOPZ pins or LCD_ENABLE and LCD_RS pins to another pins, and connect BT to:
      a) signals of Y_MIN, Y_MAX, then set BLUETOOTH_SERIAL to 3 (RX from BT to Y_MIN, TX from BT to Y_MAX)
      b) signals of Z_MIN, Z_MAX, then set BLUETOOTH_SERIAL to 1 (RX from BT to Z_MIN, TX from BT to Z_MAX)
      c) pin 17 and 18 of AUX4 connector, then set BLUETOOTH_SERIAL to 2 (RX from BT to AUX4 p18, TX from BT to AUX4 p17)

    so it would be pin 17 and 18.

    D0&D1 do not work as the usb converter also changes the line causing problems. Output works normally but input not.
  • edited March 2017
    Thanks for the response.

    After a little sleep I now understand better. I chose option A (serial 3) and also checked my BT module (which I have confirmed is at 115200 8,n,1) now when I hook it up I am getting this on the gcode window and I am getting no reply when I send command m119 (can you tell me that the text below is coming from the server or printer and if from the printer why is it cycling ? (I don't have this repeating when I use a USB cable (edit: unless I have a faulty Ramps board))

    8:41:38.849: Info:External Reset
    8:41:38.849: Info:Resetting Z correction
    8:41:38.852: Free RAM:5039
    8:41:38.852: SelectExtruder:0
    8:41:39.782: start
    8:41:39.782: Info:External Reset
    8:41:39.783: Info:Resetting Z correction
    8:41:39.783: Free RAM:5039
    8:41:39.783: SelectExtruder:0
    8:41:39.784: Error:Format error
    8:41:39.792: Resend:1
    8:41:39.792: Resend after 2798ms
    8:41:40.714: start

    Edit: Also when it is like this Repeiter-server thinks that the printer is connected but I have 0 temp (normally I have wild values when there is no temp connected like -17 and so on)
  • If it is any help I have posted the Configuration.h file. It was created with the firmware tool so I don't think there is anything funny. I do see data from the Y_Min pin on the Ramps :)
  • The text you see is coming from firmware. What it is missing are commands send from server, but I guess you did not enable this and ack in view. Looks a bit like firmware was receiving something but is not happy with what it understands.

    To rule out problems I suggest disabling printe rin server and connect directly using minicom so you can send sommands like M115, M119 for testing communication. Here you see full communication and see better if one direction has errors in communication.
  • edited March 2017
    I think there is junk coming from my Pi because when I redirect the printer to a different port, I still see stuff on my LA when I should be seeing nothing. When the server is not looking at /dev/rfcomm0 I see a 'wait' command coming from the from the firmware.
    still get no reply when I send the m119 command, so you are right in saying the ramps is not happy with that is getting from BT

    Thanks for clearing this up and I keep bashing away. I let you know of the outcome :)

    Edit: I did not turn ACK on when I posted before but i do see commands from the server in black on the gcode window :)

    Cheers
  • "wait" is coming from printer every second if no data was received. So seing that is ok and shows that baudrate is configured correctly. Only sending from pi seems to get ignored. Maybe level of that pin is modified by pullup or set as outout from a config option.
  • I think I am starting to narrow it down...

    When I hook the BT module to a FTDI (serial to usb) which is turn connected to my PC. this is the result I get from the PI
    image

    It looks like in one direction it is running fine but the other is at the worng speed, funny config in the raspberry PI or even a faulty BT module. I am about to head into work so I hope to work this out when I get back or even on my next day off :)

    Cheers for pointing me in the right direction :)
  • After a few tests I did get it to respond once to a ,119 command then the ramps board gave up accepting commands :|

    I am wondering if I have a 'few' bad BT modules or even a bad BT dongle connected to the pi. I tried a couple of other BT modules for the ramps but I can't even configure them. I wonder if they where duds (anyway I can swap out the dongle on the pi later today and if that fails then I put it down then I order some more BT modules off ebay and use a spare rasp pi with a 2nd Repetier-Server install and truck on (a bit of a waste but it will do while I wait :) )
  • Maybe just write a simple echo sketch for arduino to test it. You could even copy echo to real serial so you can connect with 2 terminals to test the thing. I had only once tested bluetooth with a RADDS board at a second UART and it worked directly. Anyway the sketch will prevent config errors from adding errors like wrong pin mode so you can concentrate on getting it running. Once it runs and you know it is configured right go back with that to firmware and then you know it must run or config is wrong. 
  • ... That's a good idea. I try it on monday (my next chance to work on it) I work with serial all of the time. I reckon it will be something simple :)

    I let you know how I go
Sign In or Register to comment.