FlashForge Dreamer 3D printer

I have purchase VirtualHere to remotely control my 3D printer over USB and view a webcam feed monitoring it. I have a Raspberry PI setup in the loft running the server daemon and my PC downstairs running the client.

I can see the two devices in the client, and I can connect to them just fine. All the drivers are installed and Device Manager shows the devices as fully installed and operational. I can connect to the camera and view the video feed fine (this is an Xbox 360 camera).

However, when I try to connect to the FlashForge Dreamer either from FlashPrint (own software) or Simplify 3D, they both list no devices available to connect to.

Can you please help me to resolve this issue?

Stephen

Start the client with the -3

Start the client with the -3 argument e.g

Vhui64.exe -3

Fantastic. I can now connect

Fantastic. I can now connect.

However, I now get an error on startup then my webcam vanishes. It is the Xbox 360 vision camera.

I spoke to soon. The webcam

I spoke to soon. The webcam started working once I rebooted the Raspberry Pi hosting it.

However, even though I can now connect to the Dreamer for printing from Simplify3D, when I send a new job it reports a write error sometimes. Once it does that the device disapears from the list and VirtualHere reports the following error:

'Error "Operation not permitted" (-1) trying to use this device (IP address:7575)'

Sounds like raspian is

Sounds like raspian is dropping the device, send me the /var/log/syslog to mail [at] virtualhere.com (mail[at]virtualhere[dot]com)

Thanks for the support

Thanks for the support Michael. I have sent you a couple of syslog dumps.

As requested I have attempted

As requested I have attempted to connect my two cameras and the 3d printer to a USB hub, this one:

http://www.amazon.co.uk/gp/product/B00VE4UJD4?psc=1&redirect=true&ref_=…

The webcams connect to it fine, but It doesn't seem to work with the dreamer. There are lights that come on when you plug something in, and with the dreamer it comes on then goes back off a few seconds later. It then does not appear in VirtualHere.

I have tried connecting your the printer to the Pi3, and the two webcams to the hub, but I am getting the same random disconnect issues.

OK im pretty sure its a

OK im pretty sure its a printer issue. I researched more about the printer and its returning a vendor id of 0315 and a product id of 0001. The vendor id is invalid which probably means its using some dodgy chinese USB->serial chip where they havent bothered to register a usb vendor officially. So i dont think we can diagnose the issue any further. If its not going to work with virtualhere i can give you a refund if you want...

Otherwise basically ask the vendor what serial chip they are using. If its a ftdi copy that might be the issue or if its prolific those chips are pretty buggy. FTDI is the best and most stable.

VirtualHere works with 3d printer quite well e.g "xyzhub" is using it so it very likely some firmware thing in the serial chip that is incompatible with virtualhere for some reason.

Thanks for the offer. I do

Thanks for the offer. I do not require a refund, it is great software and still allows me to use the webcams remotely.
You are correct the VID is 0315 and the PID is 0001. I have confirmed this in Device Manager.
The Vendor ID is not invalid. According to the pci database it belongs to SK Electronics:
http://pcidatabase.com/search.php?vendor_search_str=0315&vendor_search=…
I believe that is this company that must have produced the serial chipset:
http://www.sk-el.co.jp/en/products/

.

Actually it should be in the usb vendor id list because its a usb device. This is a different list to the pci vendor id which is only for pci devices.
The decimal "vendor id" is 789 which seems suspect. anyway i was basically hoping if we knew the vendor we could see if was any firmware updates or something for that chip...perhaps you may need to look at the pcb inside the printer if its easily viewable and see whats written on the chip. Its a long shot anyway but if its ftdi then it would point to some bug in virtualhere which might be fixable. As i know FTDI works really well with virtualhere and prolific quite well but not as well as FTDI.

This is a picture of the

This is a picture of the Mother board where the USB port is connected:
https://www.bilby3d.com.au/imgProd/ptBoardMainFFD_2.jpg
And this is the chip it is using, which is a mainstream STM microcontroller, with a USB interface.
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN11/PF252136
Doesn't seem anything non-standard can be on there.

And here is the technical

And here is the technical note and resources for the chip for implementing USB support:
http://www.st.com/web/en/catalog/tools/PF257882

So its possible they are

So its possible they are using the STM32 chip to run the printer and the usb port, kind of odd as i thought both functions have tight timing requirements, Anyway can you try this:

Right click on the Printer and select "Custom Event Handler..." then enter the line below

onReset.$VENDOR_ID$.$PRODUCT_ID$=

then click ok and see what the printer does not when you try to print.

The command above disconnects the "USB RESET" command that i send to initialize the device. Perhaps the device is not expecting this command. thats my guess at this stage.

Sorry Michael, been stuck on

Sorry Michael, been stuck on something else for a while so not been able to test this.

Doesn't seem to make any difference, but I notice that after doing the above, then going back into the Custom Event Handler setting it shows as empty again. Is that normal?

I am upgraded to the latest version of Virtual Here.

Thanks

I don't know if this is

I don't know if this is related, but this error is quite common in the raspberry pi logs:

Mar 26 23:40:03 steddypi systemd-udevd[3707]: failed to execute '/lib/udev/mtp-probe' 'mtp-probe/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3 1 28': No such file or directory

I don't know if this helps,

I don't know if this helps, but i've captured a USB trace filtering just for the FF Dreamer device on the Raspberry PI using USBMON, up until the point where communications just seems to cease. Looking at it from Simplify3D, comms just seems to hang completely.

Trace file is here:

https://dl.dropboxusercontent.com/u/7799729/usb_ff_debug.txt

Could it be the distance involved causing me issues? I am two floors a way from the FF I am accessing from my PC. It is connected via Wifi but has a good signal strength and two web cams are operating fine with it.

After the issue has occurred,

After the issue has occurred, all you get is the following. You have to reboot the Dreamer to get it to work again:

b855fb00 641991369 S Co:1:019:0 s 02 01 0000 0081 0000 0
b855fb00 641991614 C Co:1:019:0 -32 0
b855fb00 641992193 S Bi:1:019:1 -115 4096 <
b855fb00 641992310 C Bi:1:019:1 -32 0
b855f300 642126041 S Co:1:019:0 s 02 01 0000 0081 0000 0
b855f300 642126223 C Co:1:019:0 -32 0
b855f300 642126777 S Bi:1:019:1 -115 4096 <
b855f300 642126942 C Bi:1:019:1 -32 0
b855f000 642243529 S Co:1:019:0 s 02 01 0000 0081 0000 0
b855f000 642243697 C Co:1:019:0 -32 0
b855f000 642243892 S Bi:1:019:1 -115 4096 <
b855f000 642243937 C Bi:1:019:1 -32 0
b855f600 642347428 S Co:1:019:0 s 02 01 0000 0081 0000 0
b855f600 642347604 C Co:1:019:0 -32 0
b855f600 642348573 S Bi:1:019:1 -115 4096 <
b855f600 642348709 C Bi:1:019:1 -32 0

thanks for that, ill take a

thanks for that, ill take a look this week ( i didnt do much work over the easter weekend...)

Ok thats strange, even the

Ok thats strange, even the log shows a half written line at the end. Do you have a ubuntu desktop machine or other linux desktop ? Perhaps we can try with that as a virtualhere server. If that works then its very likely a bug in the raspbian kernel. I dont think its the distance, are you getting consistent ping times? e.g run ping -t <address> and see if the network ping times are consistent

Hi Michael

Yes, I am getting consistent and reliable Ping times. When it hangs it just seems to stop sending data mid packet like you see in the logs. I've traced it a couple of times and it is always the same.

I then quit and restart Simplify3D and reconnect then you see the second part of the log above, which looks like the kernel repeatedly trying to initialise and endpoint.

I am going to try connecting my macbook to it locally and printing a design, and make sure it doesn't do the same when attached locally.

Some good news (for you) and

Some good news (for you) and bad news (for me).

I just connected my Macbook to the FF Dreamer locally and tried printing from Simplify3D with the printer locally attached to USB. Once the print started, it hung in the same way with comms just stopping. So it looks like it is the printer.

One difference though is once it does this, I can click Disconnect and Reconnect and the software just reattaches and comms spring back to life. When the same thing happens with the Pi using VirtualHere, when I disconnect, the USB port vanishes so I am unable to reconnect. The only way to get it back is to power off then power back on the printer.

ok, if the usb port vanishes

ok, if the usb port vanishes its the raspbian kernel disabling the usb port for some reason. It would be written in the /var/log/syslog some like "Maybe the port is bad?" or similar error in there and perhaps the reason, maybe it cannot send a "SET ADDRESS" request or read the device descriptor from the device as its jammed.

No, there is nothing in the

No, there is nothing in the syslog. Raspian doesn't disable the port, it just vanishes on the Windows end of virtualhere.

An lsusb still shows the device and you can see post #17 above the output from usbmon on Raspian. So the port is still there. That comes above is only when the Windows virtualhere client is connected and Simplify3D is trying to probe for the port. Also VirtualHere client still shows the port as In Use.